Internet Engineering Task Force (IETF) G. Bumgardner
Request for Comments: 7450 February 2015
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) G. Bumgardner
Request for Comments: 7450 February 2015
Category: Standards Track
ISSN: 2070-1721
Automatic Multicast Tunneling
自动多播隧道
Abstract
摘要
This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.
本文档描述了自动多播隧道（AMT），一种用于将多播流量从启用多播的网络中的源传送到缺少与源网络的多播连接的接收器的协议。该协议使用UDP封装和单播复制来提供此功能。
The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.
AMT协议专门为支持快速部署而设计，只需对现有网络基础设施进行最小的更改。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7450.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7450.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Applicability ...................................................3
3. Terminology .....................................................4
3.1. Requirements Notation ......................................4
3.2. Definitions ................................................4
3.3. Abbreviations ..............................................5
4. Protocol Overview ...............................................6
4.1. General Architecture .......................................6
4.1.1. Relationship to IGMP and MLD Protocols ..............6
4.1.2. Gateways ............................................7
4.1.3. Relays .............................................10
4.1.4. Deployment .........................................13
4.1.5. Discovery ..........................................14
4.2. General Operation .........................................15
4.2.1. Message Sequences ..................................15
4.2.2. Tunneling ..........................................26
5. Protocol Description ...........................................31
5.1. Protocol Messages .........................................31
5.1.1. Relay Discovery ....................................31
5.1.2. Relay Advertisement ................................32
5.1.3. Request ............................................34
5.1.4. Membership Query ...................................35
5.1.5. Membership Update ..................................39
5.1.6. Multicast Data .....................................41
5.1.7. Teardown ...........................................43
5.2. Gateway Operation .........................................45
5.2.1. IP/IGMP/MLD Protocol Requirements ..................45
5.2.2. Pseudo-Interface Configuration .....................47
5.2.3. Gateway Service ....................................48
5.3. Relay Operation ...........................................61
5.3.1. IP/IGMP/MLD Protocol Requirements ..................61
5.3.2. Startup ............................................61
5.3.3. Running ............................................62
5.3.4. Shutdown ...........................................73
5.3.5. Response MAC Generation ............................73
5.3.6. Private Secret Generation ..........................74
6. Security Considerations ........................................74
6.1. Relays ....................................................74
6.2. Gateways ..................................................76
6.3. Encapsulated IP Packets ...................................76
7. IANA Considerations ............................................77
7.1. IPv4 and IPv6 Anycast Prefix Allocation ...................77
7.1.1. IPv4 ...............................................77
7.1.2. IPv6 ...............................................78
7.2. UDP Port Number ...........................................78
1. Introduction ....................................................3
2. Applicability ...................................................3
3. Terminology .....................................................4
3.1. Requirements Notation ......................................4
3.2. Definitions ................................................4
3.3. Abbreviations ..............................................5
4. Protocol Overview ...............................................6
4.1. General Architecture .......................................6
4.1.1. Relationship to IGMP and MLD Protocols ..............6
4.1.2. Gateways ............................................7
4.1.3. Relays .............................................10
4.1.4. Deployment .........................................13
4.1.5. Discovery ..........................................14
4.2. General Operation .........................................15
4.2.1. Message Sequences ..................................15
4.2.2. Tunneling ..........................................26
5. Protocol Description ...........................................31
5.1. Protocol Messages .........................................31
5.1.1. Relay Discovery ....................................31
5.1.2. Relay Advertisement ................................32
5.1.3. Request ............................................34
5.1.4. Membership Query ...................................35
5.1.5. Membership Update ..................................39
5.1.6. Multicast Data .....................................41
5.1.7. Teardown ...........................................43
5.2. Gateway Operation .........................................45
5.2.1. IP/IGMP/MLD Protocol Requirements ..................45
5.2.2. Pseudo-Interface Configuration .....................47
5.2.3. Gateway Service ....................................48
5.3. Relay Operation ...........................................61
5.3.1. IP/IGMP/MLD Protocol Requirements ..................61
5.3.2. Startup ............................................61
5.3.3. Running ............................................62
5.3.4. Shutdown ...........................................73
5.3.5. Response MAC Generation ............................73
5.3.6. Private Secret Generation ..........................74
6. Security Considerations ........................................74
6.1. Relays ....................................................74
6.2. Gateways ..................................................76
6.3. Encapsulated IP Packets ...................................76
7. IANA Considerations ............................................77
7.1. IPv4 and IPv6 Anycast Prefix Allocation ...................77
7.1.1. IPv4 ...............................................77
7.1.2. IPv6 ...............................................78
7.2. UDP Port Number ...........................................78
8. References .....................................................78
8.1. Normative References ......................................78
8.2. Informative References ....................................79
Acknowledgments ...................................................81
Contributors ......................................................82
Author's Address ..................................................82
8. References .....................................................78
8.1. Normative References ......................................78
8.2. Informative References ....................................79
Acknowledgments ...................................................81
Contributors ......................................................82
Author's Address ..................................................82
The advantages and benefits provided by multicast technologies are well known. There are a number of application areas that are ideal candidates for the use of multicast, including media broadcasting, video conferencing, collaboration, real-time data feeds, data replication, and software updates. Unfortunately, many of these applications lack multicast connectivity to networks that carry traffic generated by multicast sources. The reasons for the lack of connectivity vary but are primarily the result of service provider policies and network limitations.
多播技术提供的优势和好处是众所周知的。有许多应用领域是使用多播的理想候选领域，包括媒体广播、视频会议、协作、实时数据馈送、数据复制和软件更新。不幸的是，这些应用程序中的许多缺少到承载由多播源生成的流量的网络的多播连接。缺乏连通性的原因各不相同，但主要是服务提供商政策和网络限制的结果。
Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based encapsulation to overcome the aforementioned lack of multicast connectivity. AMT enables sites, hosts, or applications that do not have native multicast access to a network with multicast connectivity to a source, to request and receive Source-Specific Multicast (SSM) [RFC4607] and Any-Source Multicast (ASM) [RFC1112] traffic from a network that does provide multicast connectivity to that source.
自动多播隧道（AMT）是一种协议，它使用基于UDP的封装来克服前面提到的缺少多播连接的问题。AMT使不具有对具有到源的多播连接的网络的本机多播访问的站点、主机或应用程序能够从提供到该源的多播连接的网络请求和接收源特定多播（SSM）[RFC4607]和任何源多播（ASM）[RFC1112]流量。
This document describes a protocol that may be used to deliver multicast traffic from a multicast-enabled network to sites that lack multicast connectivity to the source network. This document does not describe any methods for sourcing multicast traffic from isolated sites, as this topic is out of scope.
本文档描述了一种协议，该协议可用于将多播流量从启用多播的网络传送到缺少与源网络的多播连接的站点。本文档不描述从孤立站点获取多播流量的任何方法，因为本主题已超出范围。
AMT is not intended to be used as a substitute for native multicast, especially in conditions or environments requiring high traffic flow. AMT uses unicast replication to reach multiple receivers, and the bandwidth cost for this replication will be higher than that required if the receivers were reachable via native multicast.
AMT不打算用作本机多播的替代品，特别是在需要高流量的条件或环境中。AMT使用单播复制到达多个接收器，如果接收器可以通过本机多播到达，则此复制的带宽成本将高于所需的带宽成本。
AMT is designed to be deployed at the border of networks possessing native multicast capabilities where access and provisioning can be managed by the AMT service provider.
AMT设计用于部署在具有本机多播功能的网络边界，AMT服务提供商可以管理访问和资源调配。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document adopts the following definitions for use in describing the protocol:
本文件采用以下定义来描述协议：
Downstream: A downstream interface or connection that faces away from the multicast distribution root or towards multicast receivers.
下游：背向多播分发根或面向多播接收器的下游接口或连接。
Upstream: An upstream interface or connection that faces a multicast distribution root or source.
上游：面向多播分发根或源的上游接口或连接。
Non-Broadcast Multi-Access (NBMA): An NBMA network or interface is one to which multiple network nodes (hosts or routers) are attached, but where packets are transmitted directly from one node to another node over a virtual circuit or physical link. NBMA networks do not support multicast or broadcast traffic -- a node that sources multicast traffic must replicate the multicast packets for separate transmission to each node that has requested the multicast traffic.
非广播多址（NBMA）：NBMA网络或接口是多个网络节点（主机或路由器）连接的网络或接口，但数据包通过虚拟电路或物理链路从一个节点直接传输到另一个节点。NBMA网络不支持多播或广播流量——源多播流量的节点必须复制多播数据包，以便单独传输到请求多播流量的每个节点。
Multicast Receiver: An entity that requests and receives multicast traffic. A receiver may be a router, host, application, or application component. The method by which a receiver transmits group membership requests and receives multicast traffic varies according to receiver type.
多播接收器：请求和接收多播流量的实体。接收器可以是路由器、主机、应用程序或应用程序组件。接收方发送组成员资格请求和接收多播流量的方法因接收方类型而异。
Group Membership Database: A group membership database describes the current multicast subscription state (also referred to as "reception state") for an interface or system. See Section 3 of [RFC3376] for a detailed definition.
组成员数据库：组成员数据库描述接口或系统的当前多播订阅状态（也称为“接收状态”）。详细定义见[RFC3376]第3节。
Reception State: The multicast subscription state of a pseudo-interface, virtual interface, or physical network interface. Often synonymous with group membership database.
接收状态：伪接口、虚拟接口或物理网络接口的多播订阅状态。通常与组成员数据库同义。
Subscription: A group or state entry in a group membership database or reception state table. The presence of a subscription entry indicates membership in an IP multicast group.
订阅：组成员数据库或接收状态表中的组或状态项。订阅条目的存在表示IP多播组中的成员身份。
Group Membership Protocol: The term "group membership protocol" is used as a generic reference to the Internet Group Management Protocol (IGMP) [RFC1112] [RFC2236] [RFC3376] or the Multicast Listener Discovery protocol [RFC2710] [RFC3810].
组成员协议：术语“组成员协议”用作对Internet组管理协议（IGMP）[RFC1112][RFC2236][RFC3376]或多播侦听器发现协议[RFC2710][RFC3810]的通用参考。
Multicast Protocol: The term "multicast protocol" is used as a generic reference to multicast routing protocols used to join or leave multicast distribution trees, such as Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601].
多播协议：术语“多播协议”用作加入或离开多播分发树的多播路由协议的通用参考，例如协议独立多播稀疏模式（PIM-SM）[RFC4601]。
Network Address Translation (NAT): Network Address Translation is the process of modifying the source IP address and port numbers carried by an IP packet while transiting a network node (see [RFC2663]). Intervening NAT devices may change the source address and port carried by messages sent from an AMT gateway to an AMT relay, possibly producing changes in protocol state and behavior.
网络地址转换（NAT）：网络地址转换是在传输网络节点时修改IP数据包携带的源IP地址和端口号的过程（参见[RFC2663]）。介入NAT设备可能会更改从AMT网关发送到AMT中继的消息所携带的源地址和端口，可能会导致协议状态和行为发生变化。
Anycast: A network addressing and routing method in which packets from a single sender are routed to the topologically nearest node in a group of potential receivers all identified by the same destination address. See [RFC4786].
选播：一种网络寻址和路由方法，其中来自单个发送者的数据包被路由到一组潜在接收者中拓扑上最近的节点，所有接收者都由相同的目的地址标识。见[RFC4786]。
AMT - Automatic Multicast Tunneling protocol.
自动多播隧道协议。
ASM - Any-Source Multicast.
ASM-任何源多播。
DoS - Denial-of-Service (attack) and DDoS for distributed DoS.
DoS-分布式DoS的拒绝服务（攻击）和DDoS。
IGMP - Internet Group Management Protocol (v1, v2, and v3).
IGMP-Internet组管理协议（v1、v2和v3）。
IP - Internet Protocol (v4 and v6).
IP-Internet协议（v4和v6）。
MAC - Message Authentication Code (or Cookie).
MAC-消息身份验证代码（或Cookie）。
MLD - Multicast Listener Discovery protocol (v1 and v2).
MLD-多播侦听器发现协议（v1和v2）。
NAT - Network Address Translation (or translation node).
NAT-网络地址转换（或转换节点）。
NBMA - Non-Broadcast Multi-Access (network, interface, or mode).
NBMA-非广播多址接入（网络、接口或模式）。
PIM - Protocol Independent Multicast.
PIM-协议独立多播。
SSM - Source-Specific Multicast.
SSM-特定于源的多播。
This section provides an informative description of the protocol. A normative description of the protocol and implementation requirements may be found in Section 5.
本节提供协议的详细说明。协议和实施要求的规范性说明见第5节。
Isolated Site | Unicast Network | Native Multicast
| (Internet) |
| |
| |
| Group Membership |
+-------+ =========================> +-------+ Multicast +------+
|Gateway| | | | Relay |<----//----|Source|
+-------+ <========================= +-------+ +------+
| Multicast Data |
| |
| |
Isolated Site | Unicast Network | Native Multicast
| (Internet) |
| |
| |
| Group Membership |
+-------+ =========================> +-------+ Multicast +------+
|Gateway| | | | Relay |<----//----|Source|
+-------+ <========================= +-------+ +------+
| Multicast Data |
| |
| |
Figure 1: Basic AMT Architecture
图1：基本AMT架构
The AMT protocol employs a client-server model in which a "gateway" sends requests to receive specific multicast traffic to a "relay" that responds by delivering the requested multicast traffic back to the gateway.
AMT协议采用客户机-服务器模型，其中“网关”向“中继”发送接收特定多播流量的请求，中继通过将请求的多播流量发送回网关进行响应。
Gateways are generally deployed within networks that lack multicast support or lack connectivity to a multicast-enabled network containing multicast sources of interest.
网关通常部署在缺乏多播支持或缺少与包含感兴趣的多播源的支持多播的网络的连接的网络中。
Relays are deployed within multicast-enabled networks that contain, or have connectivity to, multicast sources.
中继部署在支持多播的网络中，这些网络包含多播源或与多播源有连接。
AMT relies on the Internet Group Management Protocol (IGMP) [RFC3376] and the Multicast Listener Discovery (MLD) protocol [RFC3810] to provide the functionality required to manage, communicate, and act on changes in multicast group membership. A gateway or relay implementation does not necessarily require a fully functional, conforming implementation of IGMP or MLD to adhere to this
AMT依靠Internet组管理协议（IGMP）[RFC3376]和多播侦听器发现（MLD）协议[RFC3810]来提供管理、通信和对多播组成员资格的更改采取行动所需的功能。网关或中继实现不一定需要IGMP或MLD的全功能、一致性实现来遵守这一点
specification, but the protocol description that appears in this document assumes that this is the case. The minimum functional and behavioral requirements for the IGMP and MLD protocols are described in Sections 5.2.1 and 5.3.1.
规范，但本文档中出现的协议描述假定情况就是这样。第5.2.1和5.3.1节描述了IGMP和MLD协议的最低功能和行为要求。
Gateway Relay
网关中继
General _____ _____
___________ Query | | | | Query ___________
| |<------| | | |<------| |
| Host-Mode | | AMT | | AMT | |Router-Mode|
| IGMP/MLD | | | UDP | | | IGMP/MLD |
|___________|------>| |<----->| |------>|___________|
Report | | | | Report
Leave/Done | | | | Leave/Done
| | | |
IP Multicast <------| | | |<------ IP Multicast
|_____| |_____|
General _____ _____
___________ Query | | | | Query ___________
| |<------| | | |<------| |
| Host-Mode | | AMT | | AMT | |Router-Mode|
| IGMP/MLD | | | UDP | | | IGMP/MLD |
|___________|------>| |<----->| |------>|___________|
Report | | | | Report
Leave/Done | | | | Leave/Done
| | | |
IP Multicast <------| | | |<------ IP Multicast
|_____| |_____|
Figure 2: Multicast Reception State Managed by IGMP/MLD
图2:IGMP/MLD管理的多播接收状态
A gateway runs the host portion of the IGMP and MLD protocols to generate group membership updates that are sent via AMT messages to a relay. A relay runs the router portion of the IGMP and MLD protocols to process the group membership updates to produce the required changes in multicast forwarding state. A relay uses AMT messages to send incoming multicast IP datagrams to gateways according to their current group membership state.
网关运行IGMP和MLD协议的主机部分，以生成通过AMT消息发送到中继的组成员身份更新。中继运行IGMP和MLD协议的路由器部分，以处理组成员身份更新，以产生多播转发状态中所需的更改。中继使用AMT消息根据网关的当前组成员状态将传入的多播IP数据报发送到网关。
The primary function of AMT is to provide the handshaking, encapsulation, and decapsulation required to transport the IGMP and MLD messages and multicast IP datagrams between the gateways and relays. The IGMP and MLD messages that are exchanged between gateways and relays are encapsulated as complete IP datagrams within AMT control messages. Multicast IP datagrams are replicated and encapsulated in AMT data messages. All AMT messages are sent via unicast UDP/IP.
AMT的主要功能是提供在网关和中继之间传输IGMP和MLD消息以及多播IP数据报所需的握手、封装和解封装。网关和中继器之间交换的IGMP和MLD消息封装为AMT控制消息中的完整IP数据报。多播IP数据报被复制并封装在AMT数据消息中。所有AMT消息都通过单播UDP/IP发送。
The downstream side of a gateway services one or more receivers -- the gateway accepts group membership requests from receivers and forwards requested multicast traffic back to those receivers. The gateway functionality may be directly implemented in the host requesting the multicast service or within an application running on a host.
网关的下游为一个或多个接收器提供服务——网关接受来自接收器的组成员资格请求，并将请求的多播通信转发回这些接收器。网关功能可以在请求多播服务的主机中或在主机上运行的应用程序中直接实现。
The upstream side of a gateway connects to relays. A gateway sends encapsulated IGMP and MLD messages to a relay to indicate an interest in receiving specific multicast traffic.
网关的上游侧连接到继电器。网关向中继发送封装的IGMP和MLD消息，以指示对接收特定多播通信量的兴趣。
Each gateway possesses a logical pseudo-interface:
每个网关都有一个逻辑伪接口：
join/leave ---+ +----------+
| | |
V IGMPv3/MLDv2 | |
+---------+ General Query| | AMT
|IGMP/MLD |<-------------| AMT | Messages +------+
|Host-Mode| | Gateway |<-------->|UDP/IP|
|Protocol |------------->|Pseudo-I/F| +------+
+---------+ IGMP/MLD | | ^
Report | | |
Leave/Done | | V
IP Multicast <---------------------| | +---+
+----------+ |I/F|
+---+
join/leave ---+ +----------+
| | |
V IGMPv3/MLDv2 | |
+---------+ General Query| | AMT
|IGMP/MLD |<-------------| AMT | Messages +------+
|Host-Mode| | Gateway |<-------->|UDP/IP|
|Protocol |------------->|Pseudo-I/F| +------+
+---------+ IGMP/MLD | | ^
Report | | |
Leave/Done | | V
IP Multicast <---------------------| | +---+
+----------+ |I/F|
+---+
Figure 3: AMT Gateway Pseudo-Interface
图3:AMT网关伪接口
The pseudo-interface is conceptually a network interface on which the gateway executes the host portion of the IPv4/IGMP (v2 or v3) and IPv6/MLD (v1 or v2) protocols. The multicast reception state of the pseudo-interface is manipulated using the IGMP or MLD service interface. The IGMP and MLD host protocols produce IP datagrams containing group membership messages that the gateway will send to the relay. The IGMP and MLD protocols also supply the retransmission and timing behavior required for protocol robustness.
伪接口在概念上是一个网络接口，网关在其上执行IPv4/IGMP（v2或v3）和IPv6/MLD（v1或v2）协议的主机部分。使用IGMP或MLD服务接口操纵伪接口的多播接收状态。IGMP和MLD主机协议生成IP数据报，其中包含网关将发送给中继的组成员信息。IGMP和MLD协议还提供协议健壮性所需的重传和定时行为。
All AMT encapsulation, decapsulation, and relay interaction are assumed to occur within the pseudo-interface.
假设所有AMT封装、去封装和继电器交互都发生在伪接口内。
A gateway host or application may create separate interfaces for IPv4/IGMP and IPv6/MLD. A gateway host or application may also require additional pseudo-interfaces for each source or domain-specific relay address.
网关主机或应用程序可以为IPv4/IGMP和IPv6/MLD创建单独的接口。网关主机或应用程序还可能需要为每个源或特定于域的中继地址提供额外的伪接口。
Within this document, the term "gateway" may be used as a generic reference to an entity executing the gateway protocol, a gateway pseudo-interface, or a gateway device that has one or more interfaces connected to a unicast internetwork and one or more AMT gateway pseudo-interfaces.
在本文件中，术语“网关”可用作执行网关协议的实体、网关伪接口或网关设备的通用参考，该网关设备具有连接到单播互联网的一个或多个接口和一个或多个AMT网关伪接口。
The following diagram illustrates how an existing host IP stack implementation might be used to provide AMT gateway functionality to a multicast application:
下图说明了如何使用现有主机IP堆栈实现为多播应用程序提供AMT网关功能：
+-----------------------------------------------------+
|Host |
| ______________________________________ |
| | | |
| | ___________________________ | |
| | | | | |
| | | v | |
| | | +-----------+ +--------------+ |
| | | |Application| | AMT Daemon | |
| | | +-----------+ +--------------+ |
| | | join/leave | ^ data ^ AMT |
| | | | | | |
| | | +----|---|-------------|-+ |
| | | | __| |_________ | | |
| | | | | | | | |
| | | | | Sockets | | | |
| | | +-|------+-------+-|---|-+ |
| | | | | IGMP | TCP | |UDP| | |
| | | +-|------+-------+-|---|-+ |
| | | | | ^ IP | | | |
| | | | | | ____________| | | |
| | | | | | | | | |
| | | +-|-|-|----------------|-+ |
| | | | | | | |
| | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) |
| | | v | | v |
| | | +-----------+ +---+ |
| | | |Virtual I/F| |I/F| |
| | | +-----------+ +---+ |
| | | | ^ ^ |
| | | IP(IGMP)| |IP(UDP(data)) | |
| | |_________| |IP(IGMP) | |
| | | | |
| |_________________| | |
| | |
+--------------------------------------|--------------+
v
AMT Relay
+-----------------------------------------------------+
|Host |
| ______________________________________ |
| | | |
| | ___________________________ | |
| | | | | |
| | | v | |
| | | +-----------+ +--------------+ |
| | | |Application| | AMT Daemon | |
| | | +-----------+ +--------------+ |
| | | join/leave | ^ data ^ AMT |
| | | | | | |
| | | +----|---|-------------|-+ |
| | | | __| |_________ | | |
| | | | | | | | |
| | | | | Sockets | | | |
| | | +-|------+-------+-|---|-+ |
| | | | | IGMP | TCP | |UDP| | |
| | | +-|------+-------+-|---|-+ |
| | | | | ^ IP | | | |
| | | | | | ____________| | | |
| | | | | | | | | |
| | | +-|-|-|----------------|-+ |
| | | | | | | |
| | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) |
| | | v | | v |
| | | +-----------+ +---+ |
| | | |Virtual I/F| |I/F| |
| | | +-----------+ +---+ |
| | | | ^ ^ |
| | | IP(IGMP)| |IP(UDP(data)) | |
| | |_________| |IP(IGMP) | |
| | | | |
| |_________________| | |
| | |
+--------------------------------------|--------------+
v
AMT Relay
Figure 4: Virtual Interface Implementation Example
图4：虚拟接口实现示例
In this example, the host IP stack uses a virtual network interface to interact with a gateway pseudo-interface implementation.
在此示例中，主机IP堆栈使用虚拟网络接口与网关伪接口实现交互。
Use cases for gateway functionality include the following:
网关功能的用例包括以下内容：
IGMP/MLD Proxy An IGMP/MLD proxy that runs AMT on an upstream interface and router-mode IGMP/MLD on downstream interfaces to provide host access to multicast traffic via the IGMP and MLD protocols.
IGMP/MLD代理一种IGMP/MLD代理，在上游接口上运行AMT，在下游接口上运行路由器模式IGMP/MLD，以通过IGMP和MLD协议提供主机对多播流量的访问。
Virtual Network Interface A virtual network interface or pseudo-network device driver that runs AMT on a physical network interface to provide socket-layer access to multicast traffic via the IGMP/MLD service interface provided by the host IP stack.
虚拟网络接口在物理网络接口上运行AMT的虚拟网络接口或伪网络设备驱动程序，通过主机IP堆栈提供的IGMP/MLD服务接口提供对多播通信的套接字层访问。
Application An application or application component that implements and executes IGMP/MLD and AMT internally to gain access to multicast traffic.
应用程序内部实现和执行IGMP/MLD和AMT以访问多播通信的应用程序或应用程序组件。
The downstream side of a relay services gateways -- the relay accepts encapsulated IGMP and MLD group membership messages from gateways and encapsulates and forwards the requested multicast traffic back to those gateways.
中继服务网关的下游端——中继从网关接收封装的IGMP和MLD组成员消息，并封装请求的多播流量并将其转发回这些网关。
The upstream side of a relay communicates with a native multicast infrastructure -- the relay sends join and prune/leave requests towards multicast sources and accepts requested multicast traffic from those sources.
中继的上游端与本机多播基础设施通信——中继向多播源发送加入和修剪/离开请求，并接受来自这些源的请求多播流量。
Each relay possesses a logical pseudo-interface:
每个继电器都有一个逻辑伪接口：
+------------------------------+
+--------+ | Multicast Control Plane |
| |IGMP/MLD| |
| | Query* | +------------+ +----------+ |
| |<---//----|IGMPv3/MLDv2| |Multicast | |
AMT | | | |Router-Mode |->|Routing |<->
+------+ Messages | AMT |----//--->|Protocol | |Protocol | |
|UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ |
+------+ | Pseudo-| Report | | | |
^ | I/F | Leave/ +------|---------------|-------+
| | | Done | |
| | | v |
V | | IP +-----------+ |
+---+ | | Multicast |Multicast |<------+
|I/F| | |<---//-----|Forwarding |
+---+ +--------+ |Plane |<--- IP Multicast
+-----------+
+------------------------------+
+--------+ | Multicast Control Plane |
| |IGMP/MLD| |
| | Query* | +------------+ +----------+ |
| |<---//----|IGMPv3/MLDv2| |Multicast | |
AMT | | | |Router-Mode |->|Routing |<->
+------+ Messages | AMT |----//--->|Protocol | |Protocol | |
|UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ |
+------+ | Pseudo-| Report | | | |
^ | I/F | Leave/ +------|---------------|-------+
| | | Done | |
| | | v |
V | | IP +-----------+ |
+---+ | | Multicast |Multicast |<------+
|I/F| | |<---//-----|Forwarding |
+---+ +--------+ |Plane |<--- IP Multicast
+-----------+
* Queries, if generated, are consumed by the pseudo-interface.
* 查询（如果生成）将由伪接口使用。
Figure 5: AMT Relay Pseudo-Interface (Router-Based)
图5:AMT中继伪接口（基于路由器）
The pseudo-interface is conceptually a network interface on which the relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 protocols. Relays do not send unsolicited IGMPv3/MLDv2 query messages to gateways so relays must consume or discard any local queries normally generated by IGMPv3 or MLDv2. Note that the protocol mandates the use of IGMPv3 and MLDv2 for query messages. The AMT protocol is primarily intended for use in SSM applications and relies on several values provided by IGMPv3/MLDv2 to control gateway behavior.
伪接口在概念上是一个网络接口，中继在其上运行IPv4/IGMPv3和IPv6/MLDv2协议的路由器部分。中继不会向网关发送未经请求的IGMPv3/MLDv2查询消息，因此中继必须使用或放弃通常由IGMPv3或MLDv2生成的任何本地查询。请注意，该协议强制使用IGMPv3和MLDv2进行查询消息。AMT协议主要用于SSM应用，并依赖IGMPv3/MLDv2提供的几个值来控制网关行为。
A relay maintains group membership state for each gateway connected through the pseudo-interface as well as for the entire pseudo-interface (if multiple gateways are managed via a single interface). Multicast packets received on upstream interfaces on the relay are routed to the pseudo-interface where they are replicated, encapsulated, and sent to interested gateways. Changes in the pseudo-interface group membership state may trigger the transmission of multicast protocol requests upstream towards a given source or rendezvous point and cause changes in internal routing/forwarding state.
中继维护通过伪接口连接的每个网关以及整个伪接口的组成员状态（如果通过单个接口管理多个网关）。在中继上的上游接口上接收的多播数据包被路由到伪接口，在那里它们被复制、封装并发送到感兴趣的网关。伪接口组成员状态的更改可能会触发向给定源或集合点上游传输多播协议请求，并导致内部路由/转发状态的更改。
The relay pseudo-interface is an architectural abstraction used to describe AMT protocol operation. For the purposes of this document, the pseudo-interface is most easily viewed as an interface to a single gateway -- encapsulation, decapsulation, and other AMT-specific processing occurs "within" the pseudo-interface while forwarding and replication occur outside of it.
中继伪接口是用于描述AMT协议操作的体系结构抽象。在本文档中，伪接口最容易被视为单个网关的接口——封装、反封装和其他AMT特定处理发生在伪接口的“内部”，而转发和复制发生在伪接口的外部。
An alternative view is to treat the pseudo-interface as a non-broadcast multi-access (NBMA) network interface whose link layer is the unicast-only network over which AMT messages are exchanged with gateways. Individual gateways are conceptually treated as logical NBMA links on the interface. In this architectural model, group membership tracking, replication, and forwarding functions occur in the pseudo-interface.
另一种观点是将伪接口视为非广播多址（NBMA）网络接口，其链路层是仅单播的网络，AMT消息通过该网络与网关交换。各个网关在概念上被视为接口上的逻辑NBMA链路。在此体系结构模型中，组成员跟踪、复制和转发功能出现在伪接口中。
This document does not specify any particular architectural solution -- a relay developer may choose to implement and distribute protocol functionality as required to take advantage of existing relay platform services and architecture.
本文档未指定任何特定的体系结构解决方案——中继开发人员可以根据需要实施和分发协议功能，以利用现有中继平台服务和体系结构。
Within this document, the term "relay" may be used as a generic reference to an entity executing the relay protocol, a relay pseudo-interface, or a relay device that has one or more network interfaces with multicast connectivity to a native multicast infrastructure, zero or more interfaces connected to a unicast internetwork, and one or more relay pseudo-interfaces.
在本文件中，术语“中继”可用作执行中继协议的实体、中继伪接口或中继设备的通用参考，该中继设备具有一个或多个与本机多播基础设施多播连接的网络接口、零个或多个与单播互联网络连接的接口，以及一个或多个中继伪接口。
Use cases for relay functionality include the following:
继电器功能的用例包括以下内容：
Multicast Router A multicast router that runs AMT on a downstream interface to provide gateway access to multicast traffic. A "relay router" uses a multicast routing protocol (e.g., PIM-SM [RFC4601]) to construct a forwarding path for multicast traffic by sending join and prune messages to neighboring routers to join or leave multicast distribution trees for a given SSM source or ASM rendezvous point.
多播路由器在下游接口上运行AMT的多播路由器，为多播流量提供网关访问。“中继路由器”使用多播路由协议（例如，PIM-SM[RFC4601]）通过向相邻路由器发送加入和删减消息来加入或离开给定SSM源或ASM集合点的多播分发树，从而为多播业务构建转发路径。
IGMP/MLD Proxy Router An IGMP/MLD proxy that runs AMT on a downstream interface and host-mode IGMPv3/MLDv2 on an upstream interface. This "relay proxy" sends group membership reports to a local, multicast-enabled router to join and leave specific SSM or ASM groups.
IGMP/MLD代理路由器在下游接口上运行AMT，在上游接口上运行主机模式IGMPv3/MLDv2的IGMP/MLD代理。此“中继代理”将组成员报告发送到本地启用多播的路由器，以加入和离开特定的SSM或ASM组。
The AMT protocol calls for a relay deployment model that uses anycast addressing [RFC1546] [RFC4291] to pair gateways with relays.
AMT协议要求使用选播寻址[RFC1546][RFC4291]将网关与中继配对的中继部署模型。
Under this approach, one or more relays advertise a route for the same IP address prefix. To find a relay with which to communicate, a gateway sends a message to an anycast IP address within that prefix. This message is routed to the topologically nearest relay that has advertised the prefix. The relay that receives the message responds by sending its unicast address back to the gateway. The gateway uses this address as the destination address for any messages it subsequently sends to the relay.
在这种方法下，一个或多个中继为同一IP地址前缀播发路由。为了找到与之通信的中继，网关向该前缀内的选播IP地址发送消息。此消息被路由到拓扑上最近的已播发前缀的中继。接收消息的中继通过将其单播地址发送回网关进行响应。网关使用此地址作为其随后发送到中继的任何消息的目标地址。
The use of anycast addressing provides the following benefits:
使用选播寻址可提供以下好处：
o Relays may be deployed at multiple locations within a single multicast-enabled network. Relays might be installed "near" gateways to reduce bandwidth requirements and latency and to limit the number of gateways that might be serviced by a single relay.
o 中继可以部署在单个支持多播的网络中的多个位置。中继可能安装在“靠近”网关的位置，以减少带宽要求和延迟，并限制可能由单个中继提供服务的网关数量。
o Relays may be added or removed at any time, thereby allowing staged deployment, scaling, and hot-swapping -- the relay discovery process will always return the nearest operational relay.
o 可以随时添加或删除中继，从而允许分阶段部署、扩展和热交换——中继发现过程将始终返回最近的运行中继。
o Relays may take themselves offline when they exhaust resources required to service additional gateways. Existing gateway connections may be preserved, but new gateway requests would be routed to the next-nearest relay.
o 当中继耗尽为额外网关提供服务所需的资源时，它们可能会使自己脱机。现有的网关连接可能会被保留，但新的网关请求将被路由到下一个最近的中继。
Ideally, the AMT protocol would provide a universal solution for connecting receivers to multicast sources, so that any gateway could be used to access any globally advertised multicast source via publicly accessible, widely deployed relays. Unfortunately, today's Internet does not yet allow this, because many relays will lack native multicast access to sources even though they may be globally accessible via unicast.
理想情况下，AMT协议将提供一个将接收器连接到多播源的通用解决方案，以便任何网关都可以通过可公开访问、广泛部署的中继来访问任何全球公布的多播源。不幸的是，今天的互联网还不允许这样做，因为许多中继将缺少对源的本地多播访问，即使它们可以通过单播进行全局访问。
In these cases, a provider may deploy relays within their own source network to allow for multicast distribution within that network. Gateways that use these relays must use a provider-specific relay discovery mechanism or a private anycast address to obtain access to these relays.
在这些情况下，提供商可以在其自己的源网络内部署中继，以允许该网络内的多播分发。使用这些中继的网关必须使用特定于提供商的中继发现机制或专用选播地址才能访问这些中继。
AMT relies on UDP to provide best-effort delivery of multicast data to gateways. Neither AMT nor UDP provides the congestion control mechanisms required to regulate the flow of data messages passing through a network. While congestion remediation might be provided by multicast receiver applications via multicast group selection or upstream reporting mechanisms, there are no means by which to ensure that such mechanisms are employed. To limit the possible congestion across a network or wider Internet, AMT service providers are expected to deploy AMT relays near the provider's network border and its interface with edge routers. The provider must limit relay address advertisements to those edges to prevent distant gateways from being able to access a relay and potentially generate flows that consume or exceed the capacity of intervening links.
AMT依靠UDP向网关提供尽最大努力的多播数据传输。AMT和UDP都不提供调节通过网络的数据消息流所需的拥塞控制机制。虽然拥塞补救可能由多播接收器应用程序通过多播组选择或上游报告机制提供，但没有办法确保采用此类机制。为了限制网络或更广泛互联网上可能出现的拥塞，AMT服务提供商应在提供商的网络边界及其与边缘路由器的接口附近部署AMT中继。提供商必须将中继地址播发限制在这些边缘，以防止远程网关能够访问中继，并可能生成消耗或超过中间链路容量的流。
To execute the gateway portion of the protocol, a gateway requires a unicast IP address of an operational relay. This address may be obtained using a number of methods -- it may be statically assigned or dynamically chosen via some form of relay discovery process.
要执行协议的网关部分，网关需要操作中继器的单播IP地址。该地址可以使用多种方法获得——可以通过某种形式的中继发现过程静态分配或动态选择。
As described in the previous section, the AMT protocol provides a relay discovery method that relies on anycast addressing. Gateways are not required to use AMT relay discovery, but all relay implementations must support it.
如前一节所述，AMT协议提供了一种依赖于选播寻址的中继发现方法。网关不需要使用AMT中继发现，但所有中继实现都必须支持它。
The AMT protocol uses the following terminology when describing the discovery process:
AMT协议在描述发现过程时使用以下术语：
Relay Discovery Address Prefix: The anycast address prefix used to route discovery messages to a relay.
中继发现地址前缀：用于将发现消息路由到中继的选播地址前缀。
Relay Discovery Address: The anycast destination address used when sending discovery messages.
中继发现地址：发送发现消息时使用的选播目标地址。
Relay Address: The unicast IP address obtained as a result of the discovery process.
中继地址：发现过程中获得的单播IP地址。
The selection of an anycast Relay Discovery Address may be source dependent, as a relay located via relay discovery must have multicast connectivity to a desired source.
选播中继发现地址的选择可能取决于源，因为通过中继发现定位的中继必须具有到所需源的多播连接。
Similarly, the selection of a unicast Relay Address may be source dependent, as a relay contacted by a gateway to supply multicast traffic must have native multicast connectivity to the traffic source.
类似地，单播中继地址的选择可能依赖于源，因为网关接触以提供多播业务的中继必须具有到业务源的本机多播连接。
Methods that might be used to perform source-specific or group-specific relay selection are highly implementation dependent and are not further addressed by this document. Possible approaches include the use of static lookup tables, DNS-based queries, or a provision of a service interface that accepts join requests on (S,G,relay-discovery-address) or (S,G,relay-address) tuples.
可能用于执行特定于源或特定于组的中继选择的方法高度依赖于实现，本文档不作进一步说明。可能的方法包括使用静态查找表、基于DNS的查询，或提供服务接口，以接受（S、G、中继发现地址）或（S、G、中继地址）元组上的连接请求。
IANA has assigned IPv4 and IPv6 address prefixes for use in advertising and discovering publicly accessible relays.
IANA已分配IPv4和IPv6地址前缀，用于广告和发现可公开访问的中继。
A Relay Discovery Address is constructed from an address prefix by setting the low-order octet of the prefix address to 1 (for both IPv4 and IPv6). All remaining addresses within each prefix are reserved for future use.
通过将前缀地址的低阶八位组设置为1（对于IPv4和IPv6），从地址前缀构造中继发现地址。每个前缀中的所有剩余地址都保留供将来使用。
Public relays must advertise a route to the address prefix (e.g., via BGP [RFC4271]) and configure an interface to respond to the Relay Discovery Address.
公共中继必须公布到地址前缀的路由（例如，通过BGP[RFC4271]），并配置接口以响应中继发现地址。
The discovery address prefixes are described in Section 7.
第7节介绍了发现地址前缀。
The AMT protocol defines the following messages for control and encapsulation. These messages are exchanged as UDP/IP datagrams, one message per datagram.
AMT协议定义了以下用于控制和封装的消息。这些消息作为UDP/IP数据报交换，每个数据报一条消息。
Relay Discovery: Sent by gateways to solicit a Relay Advertisement from any relay. Used to find a relay with which to communicate.
中继发现：通过网关发送，以从任何中继请求中继广告。用于查找与之通信的继电器。
Relay Advertisement: Sent by relays as a response to a Relay Discovery message. Used to deliver a Relay Address to a gateway.
中继播发：由中继发送，作为对中继发现消息的响应。用于将中继地址传送到网关。
Request: Sent by gateways to solicit a Membership Query message from a relay.
请求：由网关发送以从中继请求成员资格查询消息。
Membership Query: Sent by relays as a response to a Request message. Used to deliver an encapsulated IGMPv3 or MLDv2 query message to the gateway.
成员资格查询：由中继发送，作为对请求消息的响应。用于将封装的IGMPv3或MLDv2查询消息传递到网关。
Membership Update: Sent by gateways to deliver an encapsulated IGMP or MLD report/leave/done message to a relay.
成员资格更新：由网关发送，以将封装的IGMP或MLD报告/离开/完成消息传递给中继。
Multicast Data: Sent by relays to deliver an encapsulated IP multicast datagram or datagram fragment to a gateway.
多播数据：通过中继发送，将封装的IP多播数据报或数据报片段传送到网关。
Teardown: Sent by gateways to stop the delivery of Multicast Data messages requested in an earlier Membership Update message.
拆卸：由网关发送，用于停止在早期成员资格更新消息中请求的多播数据消息的传递。
The following sections describe how these messages are exchanged to execute the protocol.
以下各节描述如何交换这些消息以执行协议。
Gateway Relay
------- -----
: :
| |
[1] |Relay Discovery |
|------------------->|
| |
| Relay Advertisement| [2]
|<-------------------|
[3] | |
: :
Gateway Relay
------- -----
: :
| |
[1] |Relay Discovery |
|------------------->|
| |
| Relay Advertisement| [2]
|<-------------------|
[3] | |
: :
Figure 6: AMT Relay Discovery Sequence
图6:AMT继电器发现序列
The following sequence describes how the Relay Discovery and Relay Advertisement messages are used to find a relay with which to communicate:
以下顺序描述如何使用中继发现和中继播发消息来查找要与其通信的中继：
1. The gateway sends a Relay Discovery message containing a random nonce to the Relay Discovery Address. If the Relay Discovery Address is an anycast address, the message is routed to the topologically nearest network node that advertises that address.
1. 网关向中继发现地址发送包含随机nonce的中继发现消息。如果中继发现地址是选播地址，则消息将路由到拓扑上最近的播发该地址的网络节点。
2. The node receiving the Relay Discovery message sends a Relay Advertisement message back to the source of the Relay Discovery message. The message carries a copy of the nonce contained in the Relay Discovery message and the unicast IP address of a relay.
2. 接收中继发现消息的节点将中继广告消息发送回中继发现消息的源。该消息携带中继发现消息中包含的nonce的副本和中继的单播IP地址。
3. When the gateway receives the Relay Advertisement message, it verifies that the nonce matches the one sent in the Relay Discovery message and, if it does, uses the Relay Address carried by the Relay Advertisement as the destination address for subsequent AMT messages.
3. 当网关接收到中继播发消息时，它验证nonce是否与中继发现消息中发送的nonce匹配，如果匹配，则使用中继播发携带的中继地址作为后续AMT消息的目标地址。
Note that the responder need not be a relay -- the responder may obtain a Relay Address by some other means and return the result in the Relay Advertisement (i.e., the responder is a load-balancer or broker).
注意，响应者不需要是中继——响应者可以通过一些其他方式获得中继地址，并在中继公告中返回结果（即，响应者是负载平衡器或代理）。
There exists a significant difference between normal IGMP and MLD behavior and that required by AMT. An IGMP/MLD router acting as a querier normally transmits query messages on a network interface to construct and refresh group membership state for the connected network. These query messages are multicast to all IGMP/MLD-enabled hosts on the network. Each host responds by multicasting report messages that describe their current multicast reception state.
正常IGMP和MLD行为与AMT所需行为之间存在显著差异。作为查询器的IGMP/MLD路由器通常在网络接口上传输查询消息，以构造和刷新所连接网络的组成员状态。这些查询消息多播到网络上所有启用IGMP/MLD的主机。每个主机通过描述其当前多播接收状态的多播报告消息进行响应。
However, AMT does not allow relays to send unsolicited query messages to gateways, as the set of active gateways may be unknown to the relay and potentially quite large. Instead, AMT requires each gateway to periodically send a message to a relay to solicit a query response. A gateway accomplishes this by sending a Request message to a relay. The relay responds by sending a Membership Query message back to the gateway. The Membership Query message carries an encapsulated query that is processed by the IGMP or MLD protocol implementation on the gateway to produce a membership/listener report. Each time the gateway receives a Membership Query message, it starts a timer whose expiration will trigger the start of a new Request->Membership Query message exchange. This timer-driven
但是，AMT不允许中继向网关发送未经请求的查询消息，因为中继可能不知道活动网关的集合，并且可能相当大。相反，AMT要求每个网关定期向中继发送消息以请求查询响应。网关通过向中继发送请求消息来实现这一点。中继通过将成员资格查询消息发送回网关进行响应。成员资格查询消息携带一个封装的查询，该查询由网关上的IGMP或MLD协议实现处理，以生成成员资格/侦听器报告。每次网关接收到成员资格查询消息时，它都会启动一个计时器，该计时器的过期将触发新请求->成员资格查询消息交换的启动。这个计时器是自动驱动的
sequence is used to mimic the transmission of a periodic query by an IGMP/MLD router. This query cycle may continue indefinitely once started by sending the initial Request message.
序列用于模拟IGMP/MLD路由器的定期查询传输。一旦通过发送初始请求消息开始，此查询周期可能会无限期地继续。
A membership update occurs when an IGMP or MLD report, leave, or done message is passed to the gateway pseudo-interface. These messages may be produced as a result of the aforementioned query processing or as a result of receiver interaction with the IGMP/MLD service interface. Each report is encapsulated and sent to the relay after the gateway has successfully established communication with the relay via a Request and Membership Query message exchange. If a report is passed to the pseudo-interface before the gateway has received a Membership Query message from the relay, the gateway may discard the report or queue the report for delivery after a Membership Query is received. Subsequent IGMP/MLD report/leave/done messages that are passed to the pseudo-interface are immediately encapsulated and transmitted to the relay.
当IGMP或MLD报告、离开或完成消息传递到网关伪接口时，会发生成员身份更新。这些消息可作为上述查询处理的结果或作为接收机与IGMP/MLD服务接口交互的结果而产生。在网关通过请求和成员查询消息交换成功地与中继建立通信后，每个报告都被封装并发送到中继。如果在网关从中继器接收到成员资格查询消息之前将报告传递到伪接口，则网关可能会丢弃该报告或在接收到成员资格查询后将报告排队以进行传递。传递到伪接口的后续IGMP/MLD报告/离开/完成消息立即被封装并传输到中继。
IGMP/MLD Pseudo-I/F Relay
-------- ---------- -----
: : :
| | Request |
| 1|-------------------->|
| | Membership Query |2
Query | | Q(0,{}) |
Timer | Start 3|<--------------------|
(QT)<--------------------------| |
| Q(0,{}) | |
|<--------------------| |
4| R({}) | Membership Update |
|-------------------->|5 R({}) |
| |====================>|6a
Join(S,G) : : :
()-------->|7 R({G:ALLOW({S})}) | Membership Update |
|-------------------->|8 R({G:ALLOW({S})}) |
| |====================>|9a Join(S,G)
| | |---------->()
: : :
| ------------|---------------------|------------
| | | | |
| | | Multicast Data | IP(S,G) |
| | | IP(S,G) 10|<--------() |
| | IP(S,G) 11|<====================| |
| | ()<--------| | |
| | | | |
: ------------:---------------------:------------
| Expired | |
(QT)-------------------------->|12 Request |
| 1|-------------------->|
| | Membership Query |2
| | Q(0,{}) |
| Start 3|<--------------------|
(QT)<--------------------------| |
| Q(0,{}) | |
|<--------------------| |
4| R({G:INCLUDE({S})}) | Membership Update |
|-------------------->|5 R({G:INCLUDE({S})})|
| |====================>|6b
Leave(S,G) : : :
()-------->|7 R({G:BLOCK({S})}) | Membership Update |
|-------------------->|8 R({G:BLOCK({S})}) |
| |====================>|9b Prune(S,G)
| | |---------->()
: : :
IGMP/MLD Pseudo-I/F Relay
-------- ---------- -----
: : :
| | Request |
| 1|-------------------->|
| | Membership Query |2
Query | | Q(0,{}) |
Timer | Start 3|<--------------------|
(QT)<--------------------------| |
| Q(0,{}) | |
|<--------------------| |
4| R({}) | Membership Update |
|-------------------->|5 R({}) |
| |====================>|6a
Join(S,G) : : :
()-------->|7 R({G:ALLOW({S})}) | Membership Update |
|-------------------->|8 R({G:ALLOW({S})}) |
| |====================>|9a Join(S,G)
| | |---------->()
: : :
| ------------|---------------------|------------
| | | | |
| | | Multicast Data | IP(S,G) |
| | | IP(S,G) 10|<--------() |
| | IP(S,G) 11|<====================| |
| | ()<--------| | |
| | | | |
: ------------:---------------------:------------
| Expired | |
(QT)-------------------------->|12 Request |
| 1|-------------------->|
| | Membership Query |2
| | Q(0,{}) |
| Start 3|<--------------------|
(QT)<--------------------------| |
| Q(0,{}) | |
|<--------------------| |
4| R({G:INCLUDE({S})}) | Membership Update |
|-------------------->|5 R({G:INCLUDE({S})})|
| |====================>|6b
Leave(S,G) : : :
()-------->|7 R({G:BLOCK({S})}) | Membership Update |
|-------------------->|8 R({G:BLOCK({S})}) |
| |====================>|9b Prune(S,G)
| | |---------->()
: : :
Figure 7: Membership Update Sequence (IGMPv3/MLDv2 Example)
图7：成员资格更新序列（IGMPv3/MLDv2示例）
The following sequence describes how the Request, Membership Query, and Membership Update messages are used to report current group membership state or changes in group membership state:
以下顺序描述了如何使用请求、成员资格查询和成员资格更新消息来报告当前组成员资格状态或组成员资格状态的更改：
1. A gateway sends a Request message to the relay that contains a random nonce and a flag indicating whether the relay should return an IGMPv3 or MLDv2 General Query.
1. 网关向中继发送一条请求消息，该消息包含一个随机的nonce和一个标志，指示中继是否应返回IGMPv3或MLDv2常规查询。
2. When the relay receives a Request message, it generates a message authentication code (MAC), typically, by computing a hash digest from the message source IP address, source UDP port, request nonce, and a private secret. The relay then sends a Membership Query message to the gateway that contains the request nonce, the MAC, and an IGMPv3 or MLDv2 General Query.
2. 当中继接收到请求消息时，它通常通过从消息源IP地址、源UDP端口、请求nonce和私密计算哈希摘要来生成消息认证码（MAC）。然后，中继向网关发送成员资格查询消息，该消息包含请求nonce、MAC和IGMPv3或MLDv2通用查询。
3. When the gateway receives a Membership Query message, it verifies that the request nonce matches the one sent in the last Request, and if it does, the gateway saves the request nonce and MAC for use in sending subsequent Membership Update messages. The gateway starts a timer whose expiration will trigger the transmission of a new Request message and extracts the encapsulated General Query message for processing by the IGMP or MLD protocol. The query timer duration is specified by the relay in the Querier's Query Interval Code (QQIC) field in the IGMPv3 or MLDv2 General Query. The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]).
3. 当网关接收到成员资格查询消息时，它将验证请求nonce是否与上一个请求中发送的请求nonce匹配，如果匹配，网关将保存请求nonce和MAC，以便在发送后续成员资格更新消息时使用。网关启动一个计时器，该计时器的到期将触发新请求消息的传输，并提取封装的通用查询消息以供IGMP或MLD协议处理。查询计时器持续时间由IGMPv3或MLDv2通用查询中查询器的查询间隔代码（QQIC）字段中的中继指定。[RFC3376]第4.1.7节和[RFC3810]第5.1.9节定义了QQIC字段。
4. The gateway's IGMP or MLD protocol implementation processes the General Query to produce a current-state report.
4. 网关的IGMP或MLD协议实现处理常规查询以生成当前状态报告。
5. When an IGMP or MLD report is passed to the pseudo-interface, the gateway encapsulates the report in a Membership Update message and sends it to the relay. The request nonce and MAC fields in the Membership Update are assigned the values from the last Membership Query message received for the corresponding group membership protocol (IGMPv3 or MLDv2).
5. 当IGMP或MLD报告传递到伪接口时，网关将报告封装在成员身份更新消息中，并将其发送到中继。成员资格更新中的请求nonce和MAC字段被分配来自为相应的组成员资格协议（IGMPv3或MLDv2）接收的上一个成员资格查询消息的值。
6. When the relay receives a Membership Update message, it computes a MAC from the message source IP address, source UDP port, request nonce, and a private secret. The relay accepts the Membership Update message if the received MAC matches the computed MAC; otherwise, the message is ignored. If the message is accepted, the relay may proceed to allocate, refresh, or modify tunnel state. This includes making any group membership,
6. 当中继接收到成员身份更新消息时，它根据消息源IP地址、源UDP端口、请求nonce和私有机密计算MAC。如果接收到的MAC与计算出的MAC匹配，则中继器接受成员资格更新消息；否则，该消息将被忽略。如果消息被接受，中继可以继续分配、刷新或修改隧道状态。这包括成为任何团体成员，
routing, and forwarding state changes, and also issuing any upstream protocol requests required to satisfy the state change. The diagram illustrates two scenarios:
路由和转发状态更改，以及发出满足状态更改所需的任何上游协议请求。该图说明了两种情况：
A. The gateway has not previously reported any group subscriptions and the report does not contain any group subscriptions, so the relay takes no action.
A.网关以前未报告任何组订阅，并且该报告不包含任何组订阅，因此中继不采取任何操作。
B. The gateway has previously reported a group subscription, so the current-state report lists all current subscriptions. The relay responds by refreshing tunnel or group state and resetting any related timers.
B.网关以前报告过组订阅，因此当前状态报告列出了所有当前订阅。继电器通过刷新隧道或组状态并重置任何相关计时器进行响应。
7. A receiver indicates to the gateway that it wishes to join (allow) or leave (block) specific multicast traffic. This request is typically made using some form of IGMP/MLD service interface (as described in Section 2 of [RFC3376] and Section 3 of [RFC3810]). The IGMP/MLD protocol responds by generating an IGMP or MLD state-change message.
7. 接收器向网关指示它希望加入（允许）或离开（阻止）特定的多播流量。该请求通常使用某种形式的IGMP/MLD服务接口（如[RFC3376]第2节和[RFC3810]第3节所述）发出。IGMP/MLD协议通过生成IGMP或MLD状态更改消息进行响应。
8. When an IGMP or MLD report/leave/done message is passed to the pseudo-interface, the gateway encapsulates the message in a Membership Update message and sends it to the relay. The request nonce and MAC fields in the Membership Update are assigned the values from the last Membership Query message received for the corresponding group membership protocol (IGMP or MLD).
8. 当IGMP或MLD报告/离开/完成消息传递到伪接口时，网关将消息封装在成员身份更新消息中，并将其发送到中继。成员资格更新中的请求nonce和MAC字段被分配来自为相应的组成员资格协议（IGMP或MLD）接收的上一个成员资格查询消息的值。
The IGMP and MLD protocols may generate multiple messages to provide robustness against packet loss -- each of these must be encapsulated in a new Membership Update message and sent to the relay. The Querier's Robustness Variable (QRV) field in the last IGMP/MLD query delivered to the IGMP/MLD protocol is typically used to specify the number of repetitions (i.e., the host adopts the QRV value as its own Robustness Variable value). The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
IGMP和MLD协议可能会生成多条消息，以提供对数据包丢失的鲁棒性——其中每一条都必须封装在新的成员身份更新消息中，并发送到中继。发送到IGMP/MLD协议的最后一次IGMP/MLD查询中的查询器鲁棒性变量（QRV）字段通常用于指定重复次数（即主机采用QRV值作为其自身的鲁棒性变量值）。QRV字段在[RFC3376]第4.1.6节和[RFC3810]第5.1.8节中定义。
9. When the relay receives a Membership Update message, it again computes a MAC from the message source IP address, source UDP port, request nonce, and a private secret. The relay accepts the Membership Update message if the received MAC matches the computed MAC; otherwise, the message is ignored. If the message is accepted, the relay processes the encapsulated IGMP/MLD and allocates, modifies, or deletes tunnel state accordingly. This includes making any group membership, routing, and forwarding
9. 当中继接收到成员身份更新消息时，它再次根据消息源IP地址、源UDP端口、请求nonce和私有机密计算MAC。如果接收到的MAC与计算出的MAC匹配，则中继器接受成员资格更新消息；否则，该消息将被忽略。如果消息被接受，中继处理封装的IGMP/MLD，并相应地分配、修改或删除隧道状态。这包括建立任何组成员资格、路由和转发
state changes, and also issuing any upstream protocol requests required to satisfy the state change. The diagram illustrates two scenarios:
状态更改，并发出满足状态更改所需的任何上游协议请求。该图说明了两种情况：
A. The gateway wishes to add a group subscription.
A.网关希望添加组订阅。
B. The gateway wishes to delete a previously reported group subscription.
B.网关希望删除以前报告的组订阅。
10. Multicast datagrams transmitted from a source travel through the native multicast infrastructure to the relay. When the relay receives a multicast IP datagram that carries a source and destination address for which a gateway has expressed an interest in receiving (via the Membership Update message), it encapsulates the datagram into a Multicast Data message and sends it to the gateway using the source IP address and UDP port carried by the Membership Update message as the destination address.
10. 从源传输的多播数据报通过本机多播基础设施传输到中继。当中继接收到多播IP数据报时，该多播IP数据报承载网关表示有兴趣接收的源地址和目的地址（通过成员身份更新消息），它将数据报封装到多播数据消息中，并使用成员身份更新消息携带的源IP地址和UDP端口作为目标地址将其发送到网关。
11. When the gateway receives a Multicast Data message, it extracts the multicast packet from the message and passes it on to the appropriate receivers.
11. 当网关接收到多播数据消息时，它从消息中提取多播数据包并将其传递给适当的接收器。
12. When the query timer expires, the gateway sends a new Request message to the relay to start a new membership update cycle.
12. 当查询计时器过期时，网关向中继发送新的请求消息，以开始新的成员资格更新周期。
The MAC-based source-authentication mechanism described above provides a simple defense against malicious attempts to exhaust relay resources via source-address spoofing. Flooding a relay with spoofed Request or Membership Update messages may consume computational resources and network bandwidth but will not result in the allocation of state, because the Request message is stateless and spoofed Membership Update messages will fail source authentication and be rejected by the relay.
上面描述的基于MAC的源身份验证机制提供了一种简单的防御措施，可以防止恶意尝试通过源地址欺骗耗尽中继资源。用伪造的请求或成员身份更新消息淹没中继可能会消耗计算资源和网络带宽，但不会导致状态分配，因为请求消息是无状态的，伪造的成员身份更新消息将使源身份验证失败并被中继拒绝。
A relay will only allocate new tunnel state if the IGMP/MLD report carried by the Membership Update message creates one or more group subscriptions.
如果成员资格更新消息携带的IGMP/MLD报告创建了一个或多个组订阅，则中继将仅分配新的隧道状态。
A relay deallocates tunnel state after one of the following events: the gateway sends a Membership Update message containing a report that results in the deletion of all remaining group subscriptions, the IGMP/MLD state expires (due to lack of refresh by the gateway), or the relay receives a valid Teardown message from the gateway (see Section 4.2.1.3).
在以下事件之一之后，中继解除分配隧道状态：网关发送成员身份更新消息，其中包含导致删除所有剩余组订阅的报告，IGMP/MLD状态过期（由于网关缺少刷新），或者中继从网关接收有效的拆卸消息（见第4.2.1.3节）。
A gateway that accepts or reports group subscriptions for both IPv4 and IPv6 addresses will send separate Request and Membership Update messages for each protocol (IPv4/IGMP and IPv6/MLD).
接受或报告IPv4和IPv6地址的组订阅的网关将为每个协议（IPv4/IGMP和IPv6/MLD）发送单独的请求和成员身份更新消息。
A gateway sends a Teardown message to a relay to request that it stop delivering Multicast Data messages to a tunnel endpoint created by an earlier Membership Update message. This message is intended to be used following a gateway address change (see Section 4.2.2.1) to stop the transmission of undeliverable or duplicate Multicast Data messages. Gateway support for the Teardown message is RECOMMENDED. Gateways are not required to send them and may instead rely on group membership to expire on the relay.
网关向中继器发送拆卸消息，请求它停止向由先前成员身份更新消息创建的隧道端点传递多播数据消息。此消息旨在在网关地址更改（见第4.2.2.1节）后用于停止无法传送或重复多播数据消息的传输。建议对拆卸消息提供网关支持。网关不需要发送它们，而是可能依赖于组成员资格在中继上过期。
Gateway Relay
------- -----
: Request :
[1] | N |
|---------------------->|
| Membership Query | [2]
| N,MAC,gADDR,gPORT |
|<======================|
[3] | Membership Update |
| ({G:INCLUDE({S})}) |
|======================>|
| |
---------------------:-----------------------:---------------------
| | | |
| | *Multicast Data | *IP Packet(S,G) |
| | gADDR,gPORT |<-----------------() |
| *IP Packet(S,G) |<======================| |
| ()<-----------------| | |
| | | |
---------------------:-----------------------:---------------------
~ ~
~ Request ~
[4] | N' |
|---------------------->|
| Membership Query | [5]
| N',MAC',gADDR',gPORT' |
|<======================|
[6] | |
| Teardown |
| N,MAC,gADDR,gPORT |
|---------------------->|
| | [7]
| Membership Update |
| ({G:INCLUDE({S})}) |
|======================>|
| |
---------------------:-----------------------:---------------------
| | | |
| | *Multicast Data | *IP Packet(S,G) |
| | gADDR',gPORT' |<-----------------() |
| *IP Packet (S,G) |<======================| |
| ()<-----------------| | |
| | | |
---------------------:-----------------------:---------------------
| |
: :
Gateway Relay
------- -----
: Request :
[1] | N |
|---------------------->|
| Membership Query | [2]
| N,MAC,gADDR,gPORT |
|<======================|
[3] | Membership Update |
| ({G:INCLUDE({S})}) |
|======================>|
| |
---------------------:-----------------------:---------------------
| | | |
| | *Multicast Data | *IP Packet(S,G) |
| | gADDR,gPORT |<-----------------() |
| *IP Packet(S,G) |<======================| |
| ()<-----------------| | |
| | | |
---------------------:-----------------------:---------------------
~ ~
~ Request ~
[4] | N' |
|---------------------->|
| Membership Query | [5]
| N',MAC',gADDR',gPORT' |
|<======================|
[6] | |
| Teardown |
| N,MAC,gADDR,gPORT |
|---------------------->|
| | [7]
| Membership Update |
| ({G:INCLUDE({S})}) |
|======================>|
| |
---------------------:-----------------------:---------------------
| | | |
| | *Multicast Data | *IP Packet(S,G) |
| | gADDR',gPORT' |<-----------------() |
| *IP Packet (S,G) |<======================| |
| ()<-----------------| | |
| | | |
---------------------:-----------------------:---------------------
| |
: :
Figure 8: Teardown Message Sequence (IGMPv3/MLDv2 Example)
图8：拆卸消息序列（IGMPv3/MLDv2示例）
The following sequence describes how the Membership Query and Teardown messages are used to detect an address change and stop the delivery of Multicast Data messages to an address:
以下序列描述了如何使用成员资格查询和拆卸消息来检测地址更改并停止向地址发送多播数据消息：
1. A gateway sends a Request message containing a random nonce to the relay.
1. 网关向中继器发送包含随机nonce的请求消息。
2. The relay sends a Membership Query message to the gateway that contains the source IP address (gADDR) and source UDP port (gPORT) values from the Request message. These values will be used to identify the tunnel should one be created by a subsequent Membership Update message.
2. 中继向网关发送成员资格查询消息，其中包含来自请求消息的源IP地址（gADDR）和源UDP端口（gPORT）值。这些值将用于标识由后续成员资格更新消息创建的隧道。
3. When the gateway receives a Membership Query message that carries the gateway address fields, it compares the gateway IP address and UDP port number values with those received in the previous Membership Query (if any). If these values do not match, this indicates that the Request message arrived at the relay carrying a different source address than the one sent previously. At this point in the sequence, no change in source address or port has occurred.
3. 当网关接收到包含网关地址字段的成员资格查询消息时，它会将网关IP地址和UDP端口号值与以前的成员资格查询（如果有）中接收到的值进行比较。如果这些值不匹配，则表示请求消息到达的中继携带的源地址与先前发送的源地址不同。在序列的这一点上，源地址或端口没有发生任何更改。
4. The gateway sends a new Request message to the relay. However, this Request message arrives at the relay carrying a different source address than that of the previous Request due to some change in network interface, address assignment, network topology, or NAT mapping.
4. 网关向中继发送新的请求消息。但是，由于网络接口、地址分配、网络拓扑或NAT映射的某些更改，此请求消息到达的中继的源地址与前一个请求的源地址不同。
5. The relay again responds by sending a Membership Query message to the gateway that contains the new source IP address (gADDR') and source UDP port (gPORT') values from the Request message.
5. 中继通过向网关发送成员资格查询消息再次作出响应，该消息包含来自请求消息的新源IP地址（gADDR'）和源UDP端口（gPORT'）值。
6. When the gateway receives the Membership Query message, it compares the gateway address and port number values against those returned in the previous Membership Query message.
6. 网关收到成员资格查询消息时，会将网关地址和端口号值与前一个成员资格查询消息中返回的值进行比较。
7. If the reported address or port has changed, the gateway sends a Teardown message to the relay that contains the request nonce, MAC, gateway IP address, and gateway port number returned in the earlier Membership Query message. The gateway may send the Teardown message multiple times where the number of repetitions is governed by the Querier's Robustness Variable (QRV) value contained in the IGMPv3/MLDv2 General Query carried by the original Membership Query (see Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810]). The gateway continues to process the new Membership Query message as usual.
7. 如果报告的地址或端口已更改，网关将向中继发送一条拆卸消息，该消息包含在先前的成员资格查询消息中返回的请求nonce、MAC、网关IP地址和网关端口号。网关可多次发送撕裂消息，其中重复次数由原始成员资格查询（参见[RFC3376]第4.1.6节和[RFC3810]第5.1.8节）携带的IGMPv3/MLDv2通用查询中包含的查询者鲁棒性变量（QRV）值控制。网关将一如既往地继续处理新的成员资格查询消息。
8. When the relay receives a Teardown message, it computes a MAC from the message source IP address, source UDP port, request nonce, and a private secret. The relay accepts the Teardown message if the received MAC matches the computed MAC; otherwise, the message is ignored. If the message is accepted, the relay makes any group membership, routing, and forwarding state changes required to stop the transmission of Multicast Data messages to that address.
8. 当中继接收到拆卸消息时，它根据消息源IP地址、源UDP端口、请求nonce和私有机密计算MAC。如果接收到的MAC与计算出的MAC相匹配，则中继器接受拆卸消息；否则，该消息将被忽略。如果消息被接受，中继将进行任何组成员资格、路由和转发状态更改，以停止向该地址传输多播数据消息。
The AMT protocol does not establish any requirements regarding what actions a gateway should take if it fails to receive a response from a relay. A gateway implementation may wait for an indefinite period of time to receive a response, may set a time limit on how long to wait for a response, may retransmit messages should the time limit be reached, may limit the number of retransmissions, or may simply report an error.
AMT协议没有建立任何关于网关在未能接收到来自中继的响应时应采取的措施的要求。网关实现可以等待无限期来接收响应，可以设置等待响应的时间限制，可以在达到时间限制时重新传输消息，可以限制重新传输的次数，或者可以简单地报告错误。
For example, a gateway may retransmit a Request message if it fails to receive a Membership Query or expected Multicast Data messages within some time period. If the gateway fails to receive any response to a Request after several retransmissions or within some maximum period of time, it may reenter the relay discovery phase in an attempt to find a new relay. This topic is addressed in more detail in Section 5.2.
例如，如果网关在某个时间段内未能接收成员资格查询或预期的多播数据消息，则可以重新传输请求消息。如果网关在多次重传后或在某个最长时间段内未能接收到对请求的任何响应，则它可能会重新进入中继发现阶段，以尝试找到新的中继。本主题将在第5.2节中详细介绍。
From the standpoint of a relay, an AMT "tunnel" is identified by the IP address and UDP port pair used as the destination address for sending encapsulated multicast IP datagrams to a gateway. In this document, we refer to this address as the tunnel endpoint address.
从中继的角度来看，AMT“隧道”由IP地址和UDP端口对标识，用作将封装的多播IP数据报发送到网关的目标地址。在本文档中，我们将此地址称为隧道端点地址。
A gateway sends a Membership Update message to a relay to add or remove group subscriptions to a tunnel endpoint. The tunnel endpoint is identified by the source IP address and source UDP port carried by the Membership Update message when it arrives at a relay (this address may differ from that carried by the message when it exited the gateway as a result of network address translation).
网关向中继发送成员身份更新消息，以添加或删除对隧道端点的组订阅。隧道端点由成员身份更新消息到达中继时携带的源IP地址和源UDP端口标识（该地址可能不同于由于网络地址转换而退出网关时携带的地址）。
The Membership Update messages sent by a single gateway host may originate from several source addresses or ports -- each unique combination represents a unique tunnel endpoint. A single gateway host may legitimately create and accept traffic on multiple tunnel endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP and IPv6/MLD protocols.
单个网关主机发送的成员身份更新消息可能来自多个源地址或端口——每个唯一的组合表示一个唯一的隧道端点。单个网关主机可以合法地在多个隧道端点上创建和接受流量，例如，网关可以为IPv4/IGMP和IPv6/MLD协议使用单独的端口。
A tunnel is "created" when a gateway sends a Membership Update message containing an IGMP or MLD membership report that creates one or more group subscriptions when none currently existed for that tunnel endpoint address.
当网关发送包含IGMP或MLD成员资格报告的成员资格更新消息时，隧道被“创建”，该报告创建了一个或多个组订阅，但该隧道端点地址当前不存在。
A tunnel ceases to exist when all group subscriptions for a tunnel endpoint are deleted. This may occur as a result of the following events:
删除隧道终结点的所有组订阅后，隧道将不再存在。这可能是由于以下事件造成的：
o The gateway sends an IGMP or MLD report, leave, or done message to the relay that deletes the last group subscription linked to the tunnel endpoint.
o 网关向中继器发送IGMP或MLD报告、离开或完成消息，中继器删除链接到隧道端点的最后一个组订阅。
o The gateway sends a Teardown message to the relay that causes it to delete any and all subscriptions bound to the tunnel endpoint.
o 网关向中继发送一条拆卸消息，使其删除绑定到隧道端点的所有订阅。
o The relay stops receiving updates from the gateway until such time that per-group or per-tunnel timers expire, causing the relay to delete the subscriptions.
o 中继停止从网关接收更新，直到每个组或每个隧道计时器过期，从而导致中继删除订阅。
The tunneling approach described above conceptually transforms a unicast-only internetwork into an NBMA link layer, over which multicast traffic may be delivered. Each relay, plus the set of all gateways using the relay, together may be thought of as being on a separate logical NBMA link, where the "link layer" address is a UDP/ IP address-port pair provided by the Membership Update message.
上述隧道方法在概念上将仅单播的因特网转换为NBMA链路层，在该链路层上可以传送多播业务。每个中继，加上使用该中继的所有网关的集合，一起可以被认为是在单独的逻辑NBMA链路上，其中“链路层”地址是由成员资格更新消息提供的UDP/IP地址端口对。
As described above, each time a relay receives a Membership Update message from a new source address-port pair, the group subscriptions described by that message apply to the tunnel endpoint identified by that address.
如上所述，每次中继从新的源地址端口对接收成员身份更新消息时，该消息描述的组订阅将应用于由该地址标识的隧道端点。
This can cause problems for a gateway if the address carried by the messages it sends to a relay changes unexpectedly. These changes may cause the relay to transmit duplicate, undeliverable, or unrequested traffic back towards the gateway or an intermediate device. This may create congestion and have negative consequences for the gateway, its network, or multicast receivers and in some cases may also produce a significant amount of ICMP traffic directed back towards the relay by a NAT, router, or gateway host.
如果网关发送到中继的消息所承载的地址发生意外更改，这可能会导致网关出现问题。这些更改可能会导致中继器向网关或中间设备发送重复的、不可交付的或未请求的通信量。这可能会造成拥塞，并对网关、其网络或多播接收器产生负面影响，在某些情况下，还可能产生大量ICMP通信量，由NAT、路由器或网关主机定向回中继。
There are several scenarios in which the address carried by messages sent by a gateway may change without that gateway's knowledge -- for example, when:
有几种情况下，网关发送的消息所承载的地址可能会在网关不知情的情况下发生更改，例如：
o The message originates from a different interface on a gateway that possesses multiple interfaces.
o 消息来自具有多个接口的网关上的不同接口。
o The DHCP assignment for a gateway interface changes.
o 网关接口的DHCP分配更改。
o The gateway roams to a different wireless network.
o 网关漫游到不同的无线网络。
o The address mapping applied by an intervening network-translation device (NAT) changes as a result of mapping expiration or routing changes in a multihomed network.
o 由于多宿网络中的映射过期或路由更改，介入网络转换设备（NAT）应用的地址映射会发生更改。
In the case where the address change occurs between the transmission of a Request message and subsequent Membership Update messages, the relay will simply ignore any Membership Update messages from the new address because MAC authentication will fail (see Section 4.2.1.2). The relay may continue to transmit previously requested traffic, but no duplication will occur, i.e., the possibility for the delivery of duplicate traffic does not arise until a Request message is received from the new address.
在发送请求消息和后续成员身份更新消息之间发生地址更改的情况下，中继将忽略来自新地址的任何成员身份更新消息，因为MAC身份验证将失败（见第4.2.1.2节）。中继可以继续传输先前请求的通信量，但不会发生重复，即，在从新地址接收到请求消息之前，不会出现发送重复通信量的可能性。
The protocol provides a method for a gateway to detect an address change and explicitly request that the relay stop sending traffic to a previous address. This process involves the Membership Query and Teardown messages and is described in Section 4.2.1.3.
该协议为网关提供了一种方法，用于检测地址更改并明确请求中继停止向以前的地址发送流量。该过程涉及成员资格查询和拆卸消息，如第4.2.1.3节所述。
The messages sent by a gateway to a relay may be subject to network address translation (NAT) -- the source IP address and UDP port carried by an IP packet sent by the gateway may be modified multiple times before arriving at the relay. In the most restrictive form of NAT, the NAT device will create a new mapping for each combination of source and destination IP address and UDP port. In this case, bidirectional communication can only be conducted by sending outgoing packets to the source address and port carried by the last incoming packet.
网关发送到中继的消息可能需要进行网络地址转换（NAT）——网关发送的IP数据包携带的源IP地址和UDP端口在到达中继之前可能会被多次修改。在最严格的NAT形式中，NAT设备将为源和目标IP地址以及UDP端口的每个组合创建新的映射。在这种情况下，双向通信只能通过将传出数据包发送到最后一个传入数据包携带的源地址和端口来进行。
Membership Update Membership Update
src: iADDR:iPORT src: eADDR:ePORT
dst: rADDR:rPORT dst: rADDR:rPORT
+---------+
| NAT |
+---------+ +-----------+ +---------+
| |---------->| |--------->| |
| Gateway | | Mapping | | Relay |
| |<----------| |<---------| |
+---------+ +-----------+ +---------+
| |
+---------+
Multicast Data Multicast Data
src: rADDR:rPORT src: rADDR:rPORT
dst: iADDR:iPORT dst: eADDR:ePORT
Membership Update Membership Update
src: iADDR:iPORT src: eADDR:ePORT
dst: rADDR:rPORT dst: rADDR:rPORT
+---------+
| NAT |
+---------+ +-----------+ +---------+
| |---------->| |--------->| |
| Gateway | | Mapping | | Relay |
| |<----------| |<---------| |
+---------+ +-----------+ +---------+
| |
+---------+
Multicast Data Multicast Data
src: rADDR:rPORT src: rADDR:rPORT
dst: iADDR:iPORT dst: eADDR:ePORT
Figure 9: Network Address Translation in AMT
图9:AMT中的网络地址转换
AMT provides automatic NAT traversal by using the source IP address and UDP port carried by the Membership Update message as received at the relay as the destination address for any Multicast Data messages the relay sends back as a result.
AMT通过使用中继接收到的成员身份更新消息携带的源IP地址和UDP端口作为中继发送回的任何多播数据消息的目标地址，提供自动NAT遍历。
The NAT mapping created by a Membership Update message will eventually expire unless it is refreshed by a passing message. This refresh will occur each time the gateway performs the periodic update required to refresh group state within the relay (see Section 4.2.1.2).
由成员资格更新消息创建的NAT映射最终将过期，除非它被传递的消息刷新。每次网关执行刷新中继内的组状态所需的定期更新时，都会发生此刷新（参见第4.2.1.2节）。
Gateway Relay
网关中继
IP:IGMP IP:IGMP
| AMT:IP:IGMP AMT:IP:IGMP |
| | | |
| | IP:UDP:AMT:IP:IGMP | |
_______ | ___ | ______ | ______ | ___ | _______
|IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP|
| | | | | | | | | | | | | | | |
| |<------------------------------------------------------->| |
|____| | | | | | | | | | | | | |____|
| |<--------------------------------------------------| |
|_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______|
| | | | |
IP AMT:IP IP:UDP:AMT:IP AMT:IP IP
IP:IGMP IP:IGMP
| AMT:IP:IGMP AMT:IP:IGMP |
| | | |
| | IP:UDP:AMT:IP:IGMP | |
_______ | ___ | ______ | ______ | ___ | _______
|IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP|
| | | | | | | | | | | | | | | |
| |<------------------------------------------------------->| |
|____| | | | | | | | | | | | | |____|
| |<--------------------------------------------------| |
|_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______|
| | | | |
IP AMT:IP IP:UDP:AMT:IP AMT:IP IP
Figure 10: AMT Encapsulation
图10:AMT封装
The IGMP and MLD messages used in AMT are exchanged as complete IP datagrams. These IP datagrams are encapsulated in AMT messages that are transmitted using UDP. The same holds true for multicast traffic -- each multicast IP datagram or datagram fragment that arrives at the relay is encapsulated in an AMT message and transmitted to one or more gateways via UDP.
AMT中使用的IGMP和MLD消息作为完整的IP数据报进行交换。这些IP数据报封装在使用UDP传输的AMT消息中。对于多播流量也是如此——到达中继的每个多播IP数据报或数据报片段都封装在AMT消息中，并通过UDP传输到一个或多个网关。
The IP protocol of the encapsulated packets need not match the IP protocol used to send the AMT messages. AMT messages sent via IPv4 may carry IPv6/MLD packets, and AMT messages sent via IPv6 may carry IPv4/IGMP packets.
封装数据包的IP协议不需要与用于发送AMT消息的IP协议匹配。通过IPv4发送的AMT消息可能携带IPv6/MLD数据包，通过IPv6发送的AMT消息可能携带IPv4/IGMP数据包。
The Checksum field contained in the UDP header of the messages requires special consideration. Of primary concern is the cost of computing a checksum on each replicated multicast packet after it is encapsulated for delivery to a gateway. Many routing/forwarding platforms do not possess the capability to compute checksums on UDP-encapsulated packets, as they may not have access to the entire datagram.
消息的UDP标头中包含的校验和字段需要特别考虑。主要关注的是在每个复制的多播数据包被封装以传送到网关之后，计算其校验和的成本。许多路由/转发平台不具备计算UDP封装数据包校验和的能力，因为它们可能无法访问整个数据报。
To avoid placing an undue burden on the relay platform, the protocol specifically allows zero-valued UDP checksums on the Multicast Data messages. This is not an issue in UDP over IPv4, as the UDP Checksum field may be set to zero. However, this is a problem for UDP over IPv6, as that protocol requires a valid, non-zero checksum in UDP datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of zero may fail to reach the gateway. This is a well-known issue for UDP-based tunneling protocols and is described in [RFC6936]. A recommended solution is described in [RFC6935].
为了避免给中继平台带来不必要的负担，该协议特别允许对多播数据消息进行零值UDP校验和。这在IPv4上的UDP中不是问题，因为UDP校验和字段可能设置为零。但是，这对于IPv6上的UDP是一个问题，因为该协议需要UDP数据报中的有效非零校验和[RFC2460]。通过IPv6发送的UDP校验和为零的消息可能无法到达网关。这是基于UDP的隧道协议的一个众所周知的问题，在[RFC6936]中有描述。[RFC6935]中描述了推荐的解决方案。
Naive encapsulation of multicast IP datagrams within AMT data messages may produce UDP datagrams that might require fragmentation if their size exceeds the MTU of the network path between the relay and a gateway. Many multicast applications, especially those related to media streaming, are designed to deliver independent data samples in separate packets, without fragmentation, to ensure that some number of complete samples can be delivered even in the presence of packet loss. To prevent or reduce undesirable fragmentation, the AMT protocol describes specific procedures for handling multicast datagrams whose encapsulation might exceed the Path MTU. These procedures are described in Section 5.3.3.6.
AMT数据消息中多播IP数据报的原始封装可能会产生UDP数据报，如果这些数据报的大小超过中继和网关之间网络路径的MTU，则可能需要分段。许多多播应用程序，特别是与媒体流相关的多播应用程序，被设计为在单独的数据包中交付独立的数据样本，而不会出现碎片，以确保即使在存在数据包丢失的情况下也可以交付一定数量的完整样本。为了防止或减少不必要的碎片，AMT协议描述了处理封装可能超过路径MTU的多播数据报的特定过程。第5.3.3.6节描述了这些程序。
This section provides a normative description of the AMT protocol.
本节提供了AMT协议的规范性说明。
The AMT protocol defines seven message types for control and encapsulation. These messages are assigned the following names and numeric identifiers:
AMT协议定义了七种用于控制和封装的消息类型。为这些消息分配了以下名称和数字标识符：
+--------------+---------------------+
| Message Type | Message Name |
+--------------+---------------------+
| 1 | Relay Discovery |
| 2 | Relay Advertisement |
| 3 | Request |
| 4 | Membership Query |
| 5 | Membership Update |
| 6 | Multicast Data |
| 7 | Teardown |
+--------------+---------------------+
+--------------+---------------------+
| Message Type | Message Name |
+--------------+---------------------+
| 1 | Relay Discovery |
| 2 | Relay Advertisement |
| 3 | Request |
| 4 | Membership Query |
| 5 | Membership Update |
| 6 | Multicast Data |
| 7 | Teardown |
+--------------+---------------------+
These messages are exchanged as IPv4 or IPv6 UDP datagrams.
这些消息作为IPv4或IPv6 UDP数据报交换。
A Relay Discovery message is used to solicit a response from a relay in the form of a Relay Advertisement message.
中继发现消息用于以中继广告消息的形式从中继请求响应。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
包含此消息的UDP/IP数据报必须携带有效的非零UDP校验和，并携带以下IP地址和UDP端口值：
Source IP Address - The IP address of the gateway interface on which the gateway will listen for a relay response. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
源IP地址—网关将在其上侦听中继响应的网关接口的IP地址。注意：该字段的值可能会在到达中继之前由于网络地址转换而改变。
Source UDP Port - The UDP port number on which the gateway will listen for a relay response. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
Source UDP Port—网关将在其上侦听中继响应的UDP端口号。注意：该字段的值可能会在到达中继之前由于网络地址转换而改变。
Destination IP Address - An anycast or unicast IP address, i.e., the Relay Discovery Address advertised by a relay.
目的地IP地址—选播或单播IP地址，即中继播发的中继发现地址。
Destination UDP Port - The AMT port number (see Section 7.2).
目标UDP端口-AMT端口号（参见第7.2节）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Relay Discovery Message Format
图11：中继发现消息格式
The protocol version number for this message is 0.
此消息的协议版本号为0。
The type number for this message is 1.
此邮件的类型号为1。
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
必须由网关设置为零并由中继忽略的保留位。
A 32-bit random value generated by the gateway and echoed by the relay in a Relay Advertisement message. This value is used by the gateway to correlate Relay Advertisement messages with Relay Discovery messages. Discovery nonce generation is described in Section 5.2.3.4.5.
网关生成的32位随机值，并由中继在中继广告消息中回显。网关使用此值将中继播发消息与中继发现消息关联起来。第5.2.3.4.5节描述了Discovery nonce生成。
The Relay Advertisement message is used to supply a gateway with a unicast IP address of a relay. A relay sends this message to a gateway when it receives a Relay Discovery message from that gateway.
中继广告消息用于向网关提供中继的单播IP地址。中继从网关接收到中继发现消息时，会将此消息发送到网关。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
包含此消息的UDP/IP数据报必须携带有效的非零UDP校验和，并携带以下IP地址和UDP端口值：
Source IP Address - The destination IP address carried by the Relay Discovery message (i.e., the Relay Discovery Address advertised by the relay).
源IP地址-中继发现消息携带的目标IP地址（即，中继发布的中继发现地址）。
Source UDP Port - The destination UDP port carried by the Relay Discovery message (i.e., the AMT port number).
源UDP端口-中继发现消息携带的目标UDP端口（即AMT端口号）。
Destination IP Address - The source IP address carried by the Relay Discovery message. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
目标IP地址—中继发现消息携带的源IP地址。注意：在到达网关之前，网络地址转换可能会改变此字段的值。
Destination UDP Port - The source UDP port carried by the Relay Discovery message. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
目标UDP端口-中继发现消息携带的源UDP端口。注意：在到达网关之前，网络地址转换可能会改变此字段的值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Relay Address (IPv4 or IPv6) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Relay Address (IPv4 or IPv6) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Relay Advertisement Message Format
图12：中继广告消息格式
The protocol version number for this message is 0.
此消息的协议版本号为0。
The type number for this message is 2.
此邮件的类型号为2。
Reserved bits that MUST be set to zero by the relay and ignored by the gateway.
必须由中继器设置为零并由网关忽略的保留位。
A 32-bit value copied from the Discovery Nonce field (Section 5.1.1.4) contained in the Relay Discovery message. The gateway uses this value to match a Relay Advertisement to a Relay Discovery message.
从中继发现消息中包含的发现Nonce字段（第5.1.1.4节）复制的32位值。网关使用此值将中继播发与中继发现消息相匹配。
The unicast IPv4 or IPv6 address of the relay. A gateway uses the length of the UDP datagram containing the Relay Advertisement message to determine the address family, i.e., length - 8 = 4 (IPv4) or 16 (IPv6). The relay returns an IP address for the protocol used to send the Relay Discovery message, i.e., an IPv4 address for an IPv4 Relay Discovery Address or an IPv6 address for an IPv6 Relay Discovery Address.
中继的单播IPv4或IPv6地址。网关使用包含中继播发消息的UDP数据报的长度来确定地址族，即长度-8=4（IPv4）或16（IPv6）。中继返回用于发送中继发现消息的协议的IP地址，即IPv4中继发现地址的IPv4地址或IPv6中继发现地址的IPv6地址。
A gateway sends a Request message to a relay to solicit a Membership Query response.
网关向中继发送请求消息以请求成员资格查询响应。
The successful delivery of this message marks the start of the first stage in the three-way handshake used to create or update state within a relay.
此消息的成功传递标志着用于创建或更新中继内状态的三方握手的第一阶段的开始。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
包含此消息的UDP/IP数据报必须携带有效的非零UDP校验和，并携带以下IP地址和UDP端口值：
Source IP Address - The IP address of the gateway interface on which the gateway will listen for a response from the relay. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
Source IP Address—网关接口的IP地址，网关将在其上侦听来自中继的响应。注意：该字段的值可能会在到达中继之前由于网络地址转换而改变。
Source UDP Port - The UDP port number on which the gateway will listen for a response from the relay. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
Source UDP Port—网关将在其上侦听来自中继的响应的UDP端口号。注意：该字段的值可能会在到达中继之前由于网络地址转换而改变。
Destination IP Address - The unicast IP address of the relay.
目标IP地址-中继的单播IP地址。
Destination UDP Port - The AMT port number.
目标UDP端口-AMT端口号。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=3 | Reserved |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=3 | Reserved |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Request Message Format
图13：请求消息格式
The protocol version number for this message is 0.
此消息的协议版本号为0。
The type number for this message is 3.
此邮件的类型号为3。
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
必须由网关设置为零并由中继忽略的保留位。
The P flag is set to indicate which group membership protocol the gateway wishes the relay to use in the Membership Query response:
设置P标志以指示网关希望中继在成员资格查询响应中使用的组成员资格协议：
Value Meaning
价值意义
0 The relay MUST respond with a Membership Query message that contains an IPv4 packet carrying an IGMPv3 General Query message. 1 The relay MUST respond with a Membership Query message that contains an IPv6 packet carrying an MLDv2 General Query message.
0中继必须使用包含承载IGMPv3常规查询消息的IPv4数据包的成员资格查询消息进行响应。1中继必须响应成员资格查询消息，该消息包含一个携带MLDv2通用查询消息的IPv6数据包。
A 32-bit random value generated by the gateway and echoed by the relay in a Membership Query message. This value is used by the relay to compute the Response MAC value and is used by the gateway to correlate Membership Query messages with Request messages. Request Nonce generation is described in Section 5.2.3.5.6.
由网关生成并由中继在成员资格查询消息中回显的32位随机值。中继使用该值计算响应MAC值，网关使用该值将成员资格查询消息与请求消息关联起来。第5.2.3.5.6节描述了请求Nonce生成。
A relay sends a Membership Query message to a gateway to solicit a Membership Update response, but only after receiving a Request message from the gateway.
中继向网关发送成员资格查询消息以请求成员资格更新响应，但仅在从网关接收到请求消息之后。
The successful delivery of this message to a gateway marks the start of the second stage in the three-way handshake used to create or update tunnel state within a relay.
将此消息成功传递到网关标志着用于在中继内创建或更新隧道状态的三向握手的第二阶段的开始。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
包含此消息的UDP/IP数据报必须携带有效的非零UDP校验和，并携带以下IP地址和UDP端口值：
Source IP Address - The destination IP address carried by the Request message (i.e., the unicast IP address of the relay).
源IP地址-请求消息携带的目标IP地址（即，中继的单播IP地址）。
Source UDP Port - The destination UDP port carried by the Request message (i.e., the AMT port number).
源UDP端口-请求消息携带的目标UDP端口（即AMT端口号）。
Destination IP Address - The source IP address carried by the Request message. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
目标IP地址—请求消息携带的源IP地址。注意：在到达网关之前，网络地址转换可能会改变此字段的值。
Destination UDP Port - The source UDP port carried by the Request message. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
目标UDP端口-请求消息携带的源UDP端口。注意：在到达网关之前，网络地址转换可能会改变此字段的值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=4 | Reserved |L|G| Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encapsulated General Query Message |
~ IPv4:IGMPv3(Membership Query) ~
| IPv6:MLDv2(Listener Query) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Gateway IP Address (IPv4 or IPv6) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=4 | Reserved |L|G| Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encapsulated General Query Message |
~ IPv4:IGMPv3(Membership Query) ~
| IPv6:MLDv2(Listener Query) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Gateway IP Address (IPv4 or IPv6) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Membership Query Message Format
图14：成员资格查询消息格式
The protocol version number for this message is 0.
此消息的协议版本号为0。
The type number for this message is 4.
此邮件的类型号为4。
Reserved bits that MUST be set to zero by the relay and ignored by the gateway.
必须由中继器设置为零并由网关忽略的保留位。
A 1-bit flag set to 1 to indicate that the relay is NOT accepting Membership Update messages from new gateway tunnel endpoints and that it will ignore any that are. A value of 0 has no special significance -- the relay may or may not be accepting Membership Update messages from new gateway tunnel endpoints. A gateway checks this flag before attempting to create new group subscription state on the relay to determine whether it should restart relay discovery. A gateway that has already created group subscriptions on the relay may ignore this flag. Support for this flag is RECOMMENDED.
设置为1的1位标志，表示中继不接受来自新网关隧道端点的成员身份更新消息，并且将忽略任何已接收的消息。值0没有特殊意义——中继可能接受也可能不接受来自新网关隧道端点的成员身份更新消息。网关在尝试在中继上创建新的组订阅状态之前检查此标志，以确定是否应重新启动中继发现。已在中继上创建组订阅的网关可能会忽略此标志。建议支持此标志。
A 1-bit flag set to 0 to indicate that the message does NOT carry the Gateway Port Number and Gateway IP Address fields, and 1 to indicate that it does. A relay implementation that supports the optional teardown procedure (see Section 5.3.3.5) SHOULD set this flag as well as the Gateway Port Number and Gateway IP Address field values. If a relay sets this flag, it MUST also include the Gateway Port Number and Gateway IP Address fields in the message. A gateway implementation that does not support the optional teardown procedure (see Section 5.2.3.7) MAY ignore this flag and the Gateway Address fields if they are present.
设置为0的1位标志表示消息未包含网关端口号和网关IP地址字段，设置为1表示消息包含网关端口号和网关IP地址字段。支持可选拆卸程序（参见第5.3.3.5节）的中继实现应设置此标志以及网关端口号和网关IP地址字段值。如果中继设置此标志，则它还必须在消息中包含网关端口号和网关IP地址字段。不支持可选拆卸程序（参见第5.2.3.7节）的网关实现可能会忽略此标志和网关地址字段（如果存在）。
A 48-bit source authentication value generated by the relay as described in Section 5.3.5. The gateway echoes this value in subsequent Membership Update messages to allow the relay to verify that the sender of a Membership Update message was the intended receiver of a Membership Query sent by the relay.
如第5.3.5节所述，由继电器生成的48位源认证值。网关在后续成员资格更新消息中回显该值，以允许中继验证成员资格更新消息的发送方是否是中继发送的成员资格查询的预期接收方。
A 32-bit value copied from the Request Nonce field (Section 5.1.3.5) carried by a Request message. The relay will have included this value in the Response MAC computation. The gateway echoes this value in subsequent Membership Update messages. The gateway also uses this value to match a Membership Query to a Request message.
从请求消息携带的请求Nonce字段（第5.1.3.5节）复制的32位值。中继将在响应MAC计算中包含该值。网关在随后的成员资格更新消息中回显此值。网关还使用此值将成员资格查询与请求消息相匹配。
An IP-encapsulated IGMP or MLD message generated by the relay. This field will contain one of the following IP datagrams:
由中继生成的IP封装的IGMP或MLD消息。此字段将包含以下IP数据报之一：
IPv4:IGMPv3 Membership Query
IPv4:IGMPv3成员资格查询
IPv6:MLDv2 Listener Query
IPv6:MLDv2侦听器查询
The source address carried by the query message should be set as described in Section 5.3.3.3.
查询消息携带的源地址应按照第5.3.3.3节所述进行设置。
The Querier's Query Interval Code (QQIC) field in the General Query is used by a relay to specify the time offset a gateway should use to schedule a new three-way handshake to refresh the group membership state within the relay (current time + Query Interval). The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810].
中继使用常规查询中查询者的查询间隔代码（QQIC）字段来指定网关应用于计划新的三方握手以刷新中继内的组成员状态的时间偏移（当前时间+查询间隔）。[RFC3376]第4.1.7节和[RFC3810]第5.1.9节定义了QQIC字段。
The Querier's Robustness Variable (QRV) field in the General Query is used by a relay to specify the number of times a gateway should retransmit unsolicited membership reports, encapsulated within Membership Update messages, and, optionally, the number of times to send a Teardown message. The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
中继使用常规查询中查询者的稳健性变量（QRV）字段来指定网关应重新传输未经请求的成员资格报告（封装在成员资格更新消息中）的次数，以及（可选）发送拆卸消息的次数。QRV字段在[RFC3376]第4.1.6节和[RFC3810]第5.1.8节中定义。
The Gateway Port Number and Gateway Address fields are present in the Membership Query message if, and only if, the G flag is set.
当且仅当设置了G标志时，网关端口号和网关地址字段才会出现在成员资格查询消息中。
A gateway need not parse the encapsulated IP datagram to determine the position of these fields within the UDP datagram containing the Membership Query message -- if the G flag is set, the gateway may simply subtract the total length of the fields (18 bytes) from the total length of the UDP datagram to obtain the offset.
网关不需要解析封装的IP数据报来确定这些字段在包含成员资格查询消息的UDP数据报中的位置——如果设置了G标志，网关可以简单地从UDP数据报的总长度中减去字段的总长度（18字节），以获得偏移量。
A 16-bit UDP port number containing a UDP port value.
包含UDP端口值的16位UDP端口号。
The relay sets this field to the value of the UDP source port of the Request message that triggered the Query message.
中继将此字段设置为触发查询消息的请求消息的UDP源端口的值。
A 16-byte IP address that, when combined with the value contained in the Gateway Port Number field, forms the gateway endpoint address that the relay will use to identify the tunnel instance, if any, created by a subsequent Membership Update message. This field may contain an IPv6 address or an IPv4 address stored as an IPv4-compatible IPv6 address, where the IPv4 address is prefixed with 96 bits set to zero (see [RFC4291]). This address must match that used by the relay to compute the value stored in the Response MAC field.
一个16字节的IP地址，当与网关端口号字段中包含的值组合时，形成网关端点地址，中继将使用该地址来标识由后续成员身份更新消息创建的隧道实例（如果有）。此字段可能包含IPv6地址或存储为IPv4兼容IPv6地址的IPv4地址，其中IPv4地址的前缀为96位设置为零（请参阅[RFC4291]）。此地址必须与中继器用于计算存储在响应MAC字段中的值的地址匹配。
A gateway sends a Membership Update message to a relay to report a change in group membership state, or to report the current group membership state in response to receiving a Membership Query message. The gateway encapsulates the IGMP or MLD message as an IP datagram within a Membership Update message and sends it to the relay, where it may (see below) be decapsulated and processed by the relay to update group membership and forwarding state.
网关向中继发送成员资格更新消息，以报告组成员资格状态的更改，或报告当前组成员资格状态，以响应接收成员资格查询消息。网关将IGMP或MLD消息封装为成员资格更新消息内的IP数据报，并将其发送到中继，在中继处，它可以（参见下文）被解除封装并由中继处理以更新组成员资格和转发状态。
A gateway cannot send a Membership Update message until it receives a Membership Query from a relay, because the gateway must copy the Request Nonce and Response MAC values carried by a Membership Query into any subsequent Membership Update messages it sends back to that relay. These values are used by the relay to verify that the sender of the Membership Update message was the recipient of the Membership Query message from which these values were copied.
网关在从中继接收到成员资格查询之前无法发送成员资格更新消息，因为网关必须将成员资格查询携带的请求Nonce和响应MAC值复制到它发送回该中继的任何后续成员资格更新消息中。中继使用这些值来验证成员资格更新消息的发件人是否是从中复制这些值的成员资格查询消息的收件人。
The successful delivery of this message to the relay marks the start of the final stage in the three-way handshake. This stage concludes when the relay successfully verifies that the sender of the Membership Update message was the recipient of a Membership Query message sent earlier. At this point, the relay may proceed to process the encapsulated IGMP or MLD message to create or update group membership and forwarding state on behalf of the gateway.
将此消息成功传递给中继标志着三方握手的最后阶段的开始。当中继成功验证成员资格更新消息的发送者是先前发送的成员资格查询消息的接收者时，此阶段结束。此时，中继器可继续处理封装的IGMP或MLD消息，以代表网关创建或更新组成员资格和转发状态。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
包含此消息的UDP/IP数据报必须携带有效的非零UDP校验和，并携带以下IP地址和UDP端口值：
Source IP Address - The IP address of the gateway interface on which the gateway will listen for Multicast Data messages from the relay. The address must be the same address used to send the initial Request message, or the message will be ignored. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
Source IP Address—网关接口的IP地址，网关将在其上侦听来自中继的多播数据消息。地址必须与用于发送初始请求消息的地址相同，否则消息将被忽略。注意：该字段的值可能会在到达中继之前由于网络地址转换而改变。
Source UDP Port - The UDP port number on which the gateway will listen for Multicast Data messages from the relay. This port must be the same port used to send the initial Request message, or the message will be ignored. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
Source UDP Port—网关将在其上侦听来自中继的多播数据消息的UDP端口号。此端口必须与用于发送初始请求消息的端口相同，否则消息将被忽略。注意：该字段的值可能会在到达中继之前由于网络地址转换而改变。
Destination IP Address - The unicast IP address of the relay.
目标IP地址-中继的单播IP地址。
Destination UDP Port - The AMT port number.
目标UDP端口-AMT端口号。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=5 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encapsulated Group Membership Update Message |
~ IPv4:IGMP(Membership Report|Leave Group) ~
| IPv6:MLD(Listener Report|Listener Done) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=5 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encapsulated Group Membership Update Message |
~ IPv4:IGMP(Membership Report|Leave Group) ~
| IPv6:MLD(Listener Report|Listener Done) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Membership Update Message Format
图15：成员资格更新消息格式
The protocol version number for this message is 0.
此消息的协议版本号为0。
The type number for this message is 5.
此邮件的类型号为5。
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
必须由网关设置为零并由中继忽略的保留位。
A 48-bit value copied from the Response MAC field (Section 5.1.4.6) in a Membership Query message. Used by the relay to perform source authentication.
从成员资格查询消息中的响应MAC字段（第5.1.4.6节）复制的48位值。由中继用来执行源身份验证。
A 32-bit value copied from the Request Nonce field in a Request or Membership Query message. Used by the relay to perform source authentication.
从请求或成员资格查询消息中的请求Nonce字段复制的32位值。由中继用来执行源身份验证。
An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP or MLD protocol running on a gateway pseudo-interface. This field will contain one of the following IP datagrams:
由运行在网关伪接口上的主机模式IGMP或MLD协议生成的IP封装IGMP或MLD消息。此字段将包含以下IP数据报之一：
IPv4:IGMPv2 Membership Report
IPv4:IGMPv2成员报告
IPv4:IGMPv2 Leave Group
IPv4:IGMPv2离开组
IPv4:IGMPv3 Membership Report
IPv4:IGMPv3成员报告
IPv6:MLDv1 Multicast Listener Report
IPv6:MLDv1多播侦听器报告
IPv6:MLDv1 Multicast Listener Done
IPv6:MLDv1多播侦听器已完成
IPv6:MLDv2 Multicast Listener Report
IPv6:MLDv2多播侦听器报告
The source address carried by the message should be set as described in Section 5.2.1.
信息携带的源地址应按照第5.2.1节的说明进行设置。
A relay sends a Multicast Data message to deliver a multicast IP datagram or datagram fragment to a gateway.
中继发送多播数据消息以将多播IP数据报或数据报片段传送到网关。
The Checksum field in the UDP header of this message MAY contain a value of zero when sent over IPv4 but SHOULD, if possible, contain a valid, non-zero value when sent over IPv6 (see Section 4.2.2.3).
当通过IPv4发送时，此消息的UDP报头中的校验和字段可能包含零值，但如果可能，当通过IPv6发送时，应包含有效的非零值（请参阅第4.2.2.3节）。
The UDP/IP datagram containing this message MUST carry the following IP address and UDP port values:
包含此消息的UDP/IP数据报必须包含以下IP地址和UDP端口值：
Source IP Address - The unicast IP address of the relay.
源IP地址-中继的单播IP地址。
Source UDP Port - The AMT port number.
源UDP端口-AMT端口号。
Destination IP Address - A tunnel endpoint IP address, i.e., the source IP address carried by the Membership Update message sent by a gateway to indicate an interest in receiving the multicast packet. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
目的地IP地址—隧道端点IP地址，即网关发送的成员身份更新消息所携带的源IP地址，用于指示对接收多播数据包的兴趣。注意：在到达网关之前，网络地址转换可能会改变此字段的值。
Destination UDP Port - A tunnel endpoint UDP port, i.e., the source UDP port carried by the Membership Update message sent by a gateway to indicate an interest in receiving the multicast packet. Note: The value of this field may be changed as a result of network address translation before arriving at the gateway.
目标UDP端口-隧道端点UDP端口，即网关发送的成员身份更新消息所携带的源UDP端口，用于表示对接收多播数据包感兴趣。注意：在到达网关之前，网络地址转换可能会改变此字段的值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=6 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ IP Multicast Packet ~
| |
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| : : : :
+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=6 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ IP Multicast Packet ~
| |
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| : : : :
+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -
Figure 16: Multicast Data Message Format
图16：多播数据消息格式
The protocol version number for this message is 0.
此消息的协议版本号为0。
The type number for this message is 6.
此邮件的类型号为6。
Reserved bits that MUST be set to zero by the relay and ignored by the gateway.
必须由中继器设置为零并由网关忽略的保留位。
A complete IPv4 or IPv6 multicast datagram or datagram fragment.
完整的IPv4或IPv6多播数据报或数据报片段。
A gateway sends a Teardown message to a relay to request that it stop sending Multicast Data messages to a tunnel endpoint created by an earlier Membership Update message. A gateway sends this message when it detects that a Request message sent to the relay carries an address that differs from that carried by a previous Request message. The gateway uses the Gateway IP Address and Gateway Port Number fields in the Membership Query message to detect these address changes.
网关向中继器发送拆卸消息，请求它停止向由早期成员身份更新消息创建的隧道端点发送多播数据消息。当网关检测到发送到中继器的请求消息所携带的地址与前一个请求消息所携带的地址不同时，就会发送此消息。网关使用成员资格查询消息中的网关IP地址和网关端口号字段来检测这些地址更改。
To provide backwards compatibility with early implementations of the AMT protocol, support for this message and associated procedures is considered OPTIONAL -- gateways are not required to send this message, and relays are not required to act upon it.
为了提供与AMT协议早期实现的向后兼容性，对该消息和相关过程的支持被认为是可选的——不需要网关来发送该消息，也不需要中继对其进行操作。
The UDP/IP datagram containing this message MUST carry a valid, non-zero UDP checksum and carry the following IP address and UDP port values:
包含此消息的UDP/IP数据报必须携带有效的非零UDP校验和，并携带以下IP地址和UDP端口值：
Source IP Address - The IP address of the gateway interface used to send the message. This address may differ from that used to send earlier messages. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
源IP地址-用于发送消息的网关接口的IP地址。此地址可能与用于发送早期邮件的地址不同。注意：该字段的值可能会在到达中继之前由于网络地址转换而改变。
Source UDP Port - The UDP port number. This port number may differ from that used to send earlier messages. Note: The value of this field may be changed as a result of network address translation before arriving at the relay.
源UDP端口-UDP端口号。此端口号可能与用于发送早期消息的端口号不同。注意：该字段的值可能会在到达中继之前由于网络地址转换而改变。
Destination IP Address - The unicast IP address of the relay.
目标IP地址-中继的单播IP地址。
Destination UDP Port - The AMT port number.
目标UDP端口-AMT端口号。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=7 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Gateway IP Address (IPv4 or IPv6) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=7 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Gateway IP Address (IPv4 or IPv6) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Membership Teardown Message Format
图17：成员资格拆卸消息格式
The protocol version number for this message is 0.
此消息的协议版本号为0。
The type number for this message is 7.
此邮件的类型号为7。
Reserved bits that MUST be set to zero by the gateway and ignored by the relay.
必须由网关设置为零并由中继忽略的保留位。
A 48-bit value copied from the Response MAC field (Section 5.1.4.6) in the last Membership Query message the relay sent to the gateway endpoint address of the tunnel to be torn down. The gateway endpoint address is provided by the Gateway IP Address and Gateway Port Number fields carried by the Membership Query message. The relay validates the Teardown message by comparing this value with one computed from the Gateway IP Address field, Gateway Port Number field, Request Nonce field, and a private secret (just as it does in the Membership Update message).
从中继发送到待拆除隧道的网关端点地址的最后一条成员资格查询消息中的响应MAC字段（第5.1.4.6节）复制的48位值。网关端点地址由成员资格查询消息携带的网关IP地址和网关端口号字段提供。中继通过将此值与从网关IP地址字段、网关端口号字段、请求Nonce字段和私密（与成员身份更新消息中的操作相同）计算的值进行比较来验证拆卸消息。
A 32-bit value copied from the Request Nonce field (Section 5.1.4.7) in the last Membership Query message the relay sent to the gateway endpoint address of the tunnel to be torn down. The gateway endpoint address is provided by the Gateway IP Address and Gateway Port Number fields carried by the Membership Query message. This value must match that used by the relay to compute the value stored in the Response MAC field.
从中继发送到要拆除的隧道的网关端点地址的最后一条成员资格查询消息中的Request Nonce字段（第5.1.4.7节）复制的32位值。网关端点地址由成员资格查询消息携带的网关IP地址和网关端口号字段提供。该值必须与中继器用于计算存储在响应MAC字段中的值相匹配。
A 16-bit UDP port number that, when combined with the value contained in the Gateway IP Address field, forms the tunnel endpoint address that the relay will use to identify the tunnel instance to tear down. The relay provides this value to the gateway using the Gateway Port Number field (Section 5.1.4.9.1) in a Membership Query message. This port number must match that used by the relay to compute the value stored in the Response MAC field.
一个16位UDP端口号，当与网关IP地址字段中包含的值组合时，形成中继将用于标识要拆除的隧道实例的隧道端点地址。中继使用成员资格查询消息中的网关端口号字段（第5.1.4.9.1节）向网关提供该值。此端口号必须与中继用来计算存储在响应MAC字段中的值的端口号匹配。
A 16-byte IP address that, when combined with the value contained in the Gateway Port Number field, forms the tunnel endpoint address that the relay will use to identify the tunnel instance to tear down. The relay provides this value to the gateway using the Gateway IP Address field (Section 5.1.4.9.2) in a Membership Query message. This field may contain an IPv6 address or an IPv4 address stored as an IPv4-compatible IPv6 address, where the IPv4 address is prefixed with 96 bits set to zero (see [RFC4291]). This address must match that used by the relay to compute the value stored in the Response MAC field.
一个16字节的IP地址，当与网关端口号字段中包含的值组合时，形成中继将用于标识要拆除的隧道实例的隧道端点地址。中继使用成员资格查询消息中的网关IP地址字段（第5.1.4.9.2节）向网关提供该值。此字段可能包含IPv6地址或存储为IPv4兼容IPv6地址的IPv4地址，其中IPv4地址的前缀为96位设置为零（请参阅[RFC4291]）。此地址必须与中继器用于计算存储在响应MAC字段中的值的地址匹配。
The following sections describe gateway implementation requirements. A non-normative discussion of gateway operation may be found in Section 4.2.
以下各节描述网关实现要求。关于网关操作的非规范性讨论见第4.2节。
Gateway operation requires a subset of host-mode IPv4/IGMP and IPv6/ MLD functionality to provide group membership tracking, query processing, and report generation. A gateway MAY use IGMPv2 (ASM), IGMPv3 (ASM and SSM), MLDv1 (ASM), or MLDv2 (ASM and SSM).
网关操作需要主机模式IPv4/IGMP和IPv6/MLD功能的子集，以提供组成员身份跟踪、查询处理和报告生成。网关可以使用IGMPv2（ASM）、IGMPv3（ASM和SSM）、MLDv1（ASM）或MLDv2（ASM和SSM）。
An application with embedded gateway functionality must provide its own implementation of this subset of the IPv4/IGMP and IPv6/MLD protocols. The service interface used to manipulate group membership state need not match that described in the IGMP and MLD specifications, but the actions taken as a result SHOULD be similar to those described in Section 5.1 of [RFC3376] and Section 6.1 of [RFC3810]. The gateway application will likely need to implement many of the same functions as a host IP stack, including checksum verification, dispatching, datagram filtering and forwarding, and IP encapsulation/decapsulation.
具有嵌入式网关功能的应用程序必须提供其自己的IPv4/IGMP和IPv6/MLD协议子集的实现。用于操纵组成员身份状态的服务接口无需与IGMP和MLD规范中所述的服务接口匹配，但由此采取的措施应与[RFC3376]第5.1节和[RFC3810]第6.1节中所述的措施类似。网关应用程序可能需要实现许多与主机IP堆栈相同的功能，包括校验和验证、调度、数据报过滤和转发以及IP封装/去封装。
The encapsulated IGMP datagrams generated by a gateway MUST conform to the descriptions found in Section 4 of [RFC3376]. These datagrams MUST possess the IP headers, header options, and header values called for in [RFC3376], with the following exception: a gateway MAY use any source address value in an IGMP report datagram, including the "unspecified" address (all octets are zero). This exception is made because a gateway pseudo-interface might not possess a valid IPv4 address, and even if an address has been assigned to the interface, that address might not be a valid link-local source address on any relay interface. It is for this reason that a relay must accept encapsulated IGMP reports regardless of the source address they carry. See Section 5.3.1.
网关生成的封装IGMP数据报必须符合[RFC3376]第4节中的描述。这些数据报必须具有[RFC3376]中要求的IP报头、报头选项和报头值，但以下情况除外：网关可以使用IGMP报告数据报中的任何源地址值，包括“未指定”地址（所有八位字节均为零）。之所以出现此异常，是因为网关伪接口可能不具有有效的IPv4地址，并且即使已将地址分配给该接口，该地址也可能不是任何中继接口上的有效链路本地源地址。正是由于这个原因，中继器必须接受封装的IGMP报告，而不管它们携带的源地址如何。见第5.3.1节。
The encapsulated MLD messages generated by a gateway MUST conform to the description found in Section 5 of [RFC3810]. These datagrams MUST possess the IP headers, header options, and header values called for in [RFC3810], with the following exception: a gateway MAY use any source address value in an MLD report datagram, including the "unspecified" address (all octets are zero). This exception is made because a gateway pseudo-interface might not possess a valid IPv6 address, and even if an address has been assigned to the interface, that address might not be a valid link-local source address on any relay interface. As with IGMP, it is for this reason that a relay must accept encapsulated MLD reports regardless of the source address they carry. See Section 5.3.1.
网关生成的封装MLD消息必须符合[RFC3810]第5节中的描述。这些数据报必须具有[RFC3810]中要求的IP报头、报头选项和报头值，但以下情况除外：网关可以使用MLD报告数据报中的任何源地址值，包括“未指定”地址（所有八位字节均为零）。之所以出现此异常，是因为网关伪接口可能不具有有效的IPv6地址，并且即使已将地址分配给该接口，该地址也可能不是任何中继接口上的有效链路本地源地址。与IGMP一样，正是由于这个原因，中继必须接受封装的MLD报告，而不管它们携带的源地址如何。见第5.3.1节。
The gateway IGMP/MLD implementation SHOULD retransmit unsolicited membership state-change reports and merge new state-change reports with pending reports as described in Section 5.1 of [RFC3376] and Section 6.1 of [RFC3810]. The number of retransmissions is specified by the relay in the Querier's Robustness Variable (QRV) field in the last General Query forwarded by the pseudo-interface. See Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
网关IGMP/MLD实现应重新传输未经请求的成员状态更改报告，并将新的状态更改报告与[RFC3376]第5.1节和[RFC3810]第6.1节所述的未决报告合并。重传次数由伪接口转发的最后一个常规查询中Querier的鲁棒性变量（QRV）字段中的中继指定。参见[RFC3376]第4.1.6节和[RFC3810]第5.1.8节。
The gateway IGMP/MLD implementation SHOULD handle General Query messages as described in Section 5.2 of [RFC3376] and Section 6.2 of [RFC3810] but MAY ignore the Max Resp Code (Maximum Response Code) field value and generate a current-state report without any delay.
网关IGMP/MLD实现应按照[RFC3376]第5.2节和[RFC3810]第6.2节所述处理一般查询消息，但可忽略最大响应代码（最大响应代码）字段值，并毫不延迟地生成当前状态报告。
An IPv4 gateway implementation MUST accept IPv4 datagrams that carry the General Query variant of the IGMPv3 Membership Query message, as described in Section 4 of [RFC3376]. The gateway MUST accept the IGMP datagram regardless of the IP source address carried by that datagram.
IPv4网关实现必须接受携带IGMPv3成员资格查询消息的常规查询变量的IPv4数据报，如[RFC3376]第4节所述。网关必须接受IGMP数据报，无论该数据报携带的IP源地址如何。
An IPv6 gateway implementation MUST accept IPv6 datagrams that carry the General Query variant of the MLDv2 Multicast Listener Query message, as described in Section 5 of [RFC3810]. The gateway MUST accept the MLD datagram regardless of the IP source address carried by that datagram.
IPv6网关实现必须接受携带MLDv2多播侦听器查询消息的通用查询变量的IPv6数据报，如[RFC3810]第5节所述。网关必须接受MLD数据报，而不管该数据报携带的IP源地址如何。
A gateway host may possess or create multiple gateway pseudo-interfaces, each with a unique configuration that describes a binding to a specific IP protocol, Relay Address, Relay Discovery Address, or upstream network interface.
网关主机可以拥有或创建多个网关伪接口，每个网关伪接口具有唯一的配置，该配置描述与特定IP协议、中继地址、中继发现地址或上游网络接口的绑定。
If a gateway implementation uses AMT relay discovery to obtain a Relay Address, it must first be supplied with a Relay Discovery Address. The Relay Discovery Address may be an anycast or unicast address. A gateway implementation may rely on a static address assignment or some form of dynamic address discovery. This specification does not require that a gateway implementation use any particular method to obtain a Relay Discovery Address -- an implementation may employ any method that returns a suitable Relay Discovery Address.
如果网关实现使用AMT中继发现来获取中继地址，则必须首先向其提供中继发现地址。中继发现地址可以是选播或单播地址。网关实现可能依赖于静态地址分配或某种形式的动态地址发现。本规范不要求网关实现使用任何特定方法来获取中继发现地址——实现可以使用任何返回适当中继发现地址的方法。
Before a gateway implementation can execute the AMT protocol to request and receive multicast traffic, it must be supplied with a unicast Relay Address. A gateway implementation may rely on static address assignment or support some form of dynamic address discovery. This specification does not require the use of any particular method to obtain a Relay Address -- an implementation may employ any method that returns a suitable Relay Address.
在网关实现可以执行AMT协议以请求和接收多播流量之前，必须为其提供单播中继地址。网关实现可能依赖于静态地址分配或支持某种形式的动态地址发现。本规范不要求使用任何特定方法来获取中继地址——实现可以使用任何返回合适中继地址的方法。
A gateway host that possesses multiple network interfaces or addresses may allow for an explicit selection of the interface to use when communicating with a relay. The selection might be made to satisfy connectivity, tunneling, or IP protocol requirements.
拥有多个网络接口或地址的网关主机可允许在与中继器通信时显式选择要使用的接口。选择可能是为了满足连接性、隧道或IP协议要求。
A gateway implementation that supports retransmission MAY require the following information:
支持重传的网关实现可能需要以下信息：
Discovery Timeout Initial time to wait for a response to a Relay Discovery message.
发现超时等待对中继发现消息的响应的初始时间。
Maximum Relay Discovery Retransmission Count Maximum number of Relay Discovery retransmissions to allow before terminating relay discovery and reporting an error.
最大中继发现重传计数终止中继发现和报告错误之前允许的最大中继发现重传次数。
Request Timeout Initial time to wait for a response to a Request message.
请求超时等待请求消息响应的初始时间。
Maximum Request Retransmission Count Maximum number of Request retransmissions to allow before abandoning a relay and restarting relay discovery or reporting an error.
最大请求重传计数放弃中继并重新启动中继发现或报告错误之前允许的最大请求重传次数。
Maximum Retries Count for "Destination Unreachable" The maximum number of times a gateway should attempt to send the same Request or Membership Update message after receiving an ICMP Destination Unreachable message.
“目标不可访问”的最大重试次数网关在收到ICMP目标不可访问消息后应尝试发送相同请求或成员身份更新消息的最大次数。
In the following descriptions, a gateway pseudo-interface is treated as a passive entity managed by a gateway service. The gateway pseudo-interface provides the state, and the gateway service provides the processing. The term "gateway" is used when describing service behavior with respect to a single pseudo-interface.
在以下描述中，网关伪接口被视为由网关服务管理的被动实体。网关伪接口提供状态，网关服务提供处理。术语“网关”用于描述关于单个伪接口的服务行为。
When a gateway pseudo-interface is started, the gateway service begins listening for AMT messages sent to the UDP endpoint(s) associated with the pseudo-interface and for any locally generated IGMP/MLD messages passed to the pseudo-interface. The handling of these messages is described below.
当网关伪接口启动时，网关服务开始侦听发送到与伪接口关联的UDP端点的AMT消息以及传递到伪接口的任何本地生成的IGMP/MLD消息。这些消息的处理如下所述。
When the pseudo-interface is enabled, the gateway service MAY:
启用伪接口时，网关服务可能：
o Optionally execute the relay discovery procedure described in Section 5.2.3.4.
o 可选地执行第5.2.3.4节所述的继电器发现程序。
o Optionally execute the membership query procedure described in Section 5.2.3.5 to start the periodic membership update cycle.
o 可选地执行第5.2.3.5节中描述的成员资格查询程序，以开始定期成员资格更新周期。
A gateway MUST ignore any datagram it receives that cannot be interpreted as a Relay Advertisement, Membership Query, or Multicast Data message. The handling of Relay Advertisement, Membership Query, and Multicast Data messages is addressed in the sections that follow.
网关必须忽略它接收到的不能解释为中继播发、成员资格查询或多播数据消息的任何数据报。中继播发、成员资格查询和多播数据消息的处理将在下面的部分中介绍。
A gateway that conforms to this specification MUST ignore any message with a Version field value other than zero.
符合此规范的网关必须忽略版本字段值不是零的任何消息。
While listening for AMT messages, a gateway may be notified that an ICMP Destination Unreachable message was received as a result of an AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
在侦听AMT消息时，可能会通知网关由于AMT消息传输而接收到ICMP目的地不可访问消息。第5.2.3.9节描述了ICMP目标不可到达消息的处理。
A gateway may receive Multicast Data messages after it sends a Membership Update message to a relay that adds a group subscription. The gateway may continue to receive Multicast Data messages long after the gateway sends a Membership Update message that deletes existing group subscriptions. The gateway MUST be prepared to receive these messages at any time but MAY ignore them or discard their contents if the gateway no longer has any interest in receiving the multicast datagrams contained within them.
网关可以在向添加组订阅的中继发送成员资格更新消息之后接收多播数据消息。网关可以在网关发送删除现有组订阅的成员资格更新消息后很长时间内继续接收多播数据消息。网关必须随时准备接收这些消息，但如果网关不再有兴趣接收其中包含的多播数据报，则可以忽略这些消息或丢弃其内容。
A gateway MUST ignore a Multicast Data message if it fails to satisfy any of the following requirements:
如果网关无法满足以下任何要求，则必须忽略多播数据消息：
o The source IP address and UDP port carried by the Multicast Data message MUST be equal to the destination IP address and UDP port carried by the matching Membership Update message (i.e., the current Relay Address).
o 多播数据消息携带的源IP地址和UDP端口必须等于匹配成员身份更新消息携带的目标IP地址和UDP端口（即当前中继地址）。
o The destination address carried by the encapsulated IP datagram MUST fall within the multicast address allocation assigned to the relevant IP protocol, i.e., 224.0.0.0/4 for IPv4 and ff00::/8 for IPv6.
o 封装的IP数据报携带的目标地址必须在分配给相关IP协议的多播地址分配范围内，即IPv4为224.0.0.0/4，IPv6为ff00:：/8。
The gateway extracts the encapsulated IP datagram and forwards it to the local IP protocol implementation for checksum verification, fragmented datagram reassembly, source and group filtering, and transport-layer protocol processing.
网关提取封装的IP数据报并将其转发给本地IP协议实现，以进行校验和验证、碎片数据报重组、源和组过滤以及传输层协议处理。
Because AMT uses UDP encapsulation to deliver multicast datagrams to gateways, it qualifies as a tunneling protocol subject to the limitations described in [RFC6936]. If supported, a gateway SHOULD employ the solution described in [RFC6936] to ensure that the local IP stack does not discard IPv6 datagrams with zero checksums. If Multicast Data message datagrams are processed directly within the gateway (instead of the host IP stack), the gateway MUST NOT discard any of these datagrams because they carry a UDP checksum of zero.
由于AMT使用UDP封装将多播数据报传送到网关，因此它符合[RFC6936]中所述限制条件下的隧道协议。如果支持，网关应采用[RFC6936]中描述的解决方案，以确保本地IP堆栈不会丢弃校验和为零的IPv6数据报。如果多播数据消息数据报直接在网关（而不是主机IP堆栈）内处理，则网关不得丢弃任何这些数据报，因为它们的UDP校验和为零。
This section describes gateway requirements related to the relay discovery message sequence described in Section 4.2.1.1.
本节描述了与第4.2.1.1节中描述的中继发现消息序列相关的网关要求。
A gateway may start or restart the relay discovery procedure in response to the following events:
网关可以启动或重新启动中继发现过程，以响应以下事件：
o When a gateway pseudo-interface is started (enabled).
o 当网关伪接口启动（启用）时。
o When the gateway wishes to report a group subscription when none currently exist.
o 当网关希望报告当前不存在的组订阅时。
o Before sending the next Request message in a membership update cycle, i.e., each time the query timer expires (see below).
o 在成员资格更新周期中发送下一条请求消息之前，即每次查询计时器过期时（见下文）。
o After the gateway fails to receive a response to a Request message.
o 网关无法接收对请求消息的响应后。
o After the gateway receives a Membership Query message with the L flag set to 1.
o 网关收到L标志设置为1的成员资格查询消息后。
A gateway sends a Relay Discovery message to a relay to start the relay discovery process.
网关向中继发送中继发现消息以启动中继发现过程。
The gateway MUST send the Relay Discovery message using the current Relay Discovery Address and AMT port number as the destination. The Discovery Nonce value in the Relay Discovery message MUST be computed as described in Section 5.2.3.4.5.
网关必须使用当前中继发现地址和AMT端口号作为目标发送中继发现消息。必须按照第5.2.3.4.5节所述计算中继发现消息中的发现Nonce值。
The gateway MUST save a copy of the Relay Discovery message or save the Discovery Nonce value for possible retransmission and verification of a Relay Advertisement response.
网关必须保存中继发现消息的副本或保存发现当前值，以便可能的重新传输和验证中继播发响应。
When a gateway sends a Relay Discovery message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
当网关发送中继发现消息时，可能会通知它由于先前的AMT消息传输而接收到ICMP目标不可到达消息。第5.2.3.9节描述了ICMP目标不可到达消息的处理。
A gateway MAY retransmit a Relay Discovery message if it does not receive a matching Relay Advertisement message within some timeout period. If the gateway retransmits the message multiple times, the timeout period SHOULD be adjusted to provide a random exponential back-off. The RECOMMENDED timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and a RECOMMENDED maximum_timeout of 120 seconds (which is the recommended minimum NAT mapping timeout described in [RFC4787]).
如果网关在某个超时时间段内未接收到匹配的中继播发消息，则可以重新传输中继发现消息。如果网关多次重新传输消息，则应调整超时时间以提供随机指数回退。建议的超时是[initial_timeout，MIN（initial_timeout*2^ retry_count，maximum_timeout）]范围内的随机值，建议的初始_超时为1秒，建议的最大_超时为120秒（这是[RFC4787]中描述的建议的最小NAT映射超时）。
When a gateway receives a Relay Advertisement message, it must first determine whether it should accept or ignore the message. A gateway MUST ignore a Relay Advertisement message if it fails to satisfy any of the following requirements:
当网关接收到中继广告消息时，它必须首先确定是接受还是忽略该消息。如果网关未能满足以下任何要求，则必须忽略中继播发消息：
o The gateway MUST be waiting for a Relay Advertisement message.
o 网关必须等待中继播发消息。
o The Discovery Nonce value contained in the Relay Advertisement message MUST be equal to the Discovery Nonce value contained in the Relay Discovery message.
o 中继播发消息中包含的发现Nonce值必须等于中继发现消息中包含的发现Nonce值。
o The source IP address and UDP port of the Relay Advertisement message MUST be equal to the destination IP address and UDP port of the matching Relay Discovery message.
o 中继播发消息的源IP地址和UDP端口必须等于匹配中继发现消息的目标IP地址和UDP端口。
Once a gateway receives a Relay Advertisement response to a Relay Discovery message, it SHOULD ignore any other Relay Advertisements that arrive on the AMT interface until it sends a new Relay Discovery message.
一旦网关收到对中继发现消息的中继播发响应，它应该忽略到达AMT接口的任何其他中继播发，直到它发送新的中继发现消息。
If a gateway executes the relay discovery procedure at the start of each membership update cycle and the Relay Address returned in the latest Relay Advertisement message differs from the address returned in a previous Relay Advertisement message, then the gateway SHOULD send a Teardown message (if supported) to the old Relay Address,
如果网关在每个成员资格更新周期开始时执行中继发现过程，并且在最新的中继公告消息中返回的中继地址与在先前的中继公告消息中返回的地址不同，则网关应向旧的中继地址发送拆卸消息（如果支持），
using information from the last Membership Query message received from that relay, as described in Section 5.2.3.7. This behavior is illustrated in the following diagram.
如第5.2.3.7节所述，使用从该中继接收的最后一条成员资格查询消息中的信息。下图说明了此行为。
Gateway Relay-1
------- -------
: :
Query Expired | |
Timer (QT)-------->| |
| Relay Discovery |
|------------------->|
| |
| Relay Advertisement|
|<-------------------|
| |
| Request |
|------------------->|
| |
| Membership Query |
|<===================|
Start | |
(QT)<--------| Membership Update |
|===================>|
| |
~ ~ Relay-2
Expired | | -------
(QT)-------->| | :
| Relay Discovery | |
|------------------------------------>|
| | |
| Relay Advertisement| |
|<------------------------------------|
| | |
| Teardown | |
|------------------->| |
| | |
| Request | |
|------------------------------------>|
| | |
| Membership Query | |
|<====================================|
Start | | |
(QT)<--------| Membership Update | |
|====================================>|
| | |
: : :
Gateway Relay-1
------- -------
: :
Query Expired | |
Timer (QT)-------->| |
| Relay Discovery |
|------------------->|
| |
| Relay Advertisement|
|<-------------------|
| |
| Request |
|------------------->|
| |
| Membership Query |
|<===================|
Start | |
(QT)<--------| Membership Update |
|===================>|
| |
~ ~ Relay-2
Expired | | -------
(QT)-------->| | :
| Relay Discovery | |
|------------------------------------>|
| | |
| Relay Advertisement| |
|<------------------------------------|
| | |
| Teardown | |
|------------------->| |
| | |
| Request | |
|------------------------------------>|
| | |
| Membership Query | |
|<====================================|
Start | | |
(QT)<--------| Membership Update | |
|====================================>|
| | |
: : :
Figure 18: Teardown after Relay Address Change
图18：中继地址更改后的拆卸
The discovery nonce MUST be a random, non-zero 32-bit value and, if possible, SHOULD be computed using a cryptographically secure pseudorandom number generator. A new nonce SHOULD be generated each time the gateway restarts the relay discovery process. The same nonce SHOULD be used when retransmitting a Relay Discovery message.
发现nonce必须是随机的、非零的32位值，如果可能，应该使用加密安全的伪随机数生成器进行计算。每次网关重新启动中继发现过程时，都应生成一个新的nonce。在重新传输中继发现消息时，应使用相同的nonce。
This section describes gateway requirements related to the membership update message sequence described in Section 4.2.1.2.
本节描述了与第4.2.1.2节所述成员资格更新消息序列相关的网关要求。
A gateway may send a Request message to start a membership update cycle (following the optional relay discovery procedure) in response to the following events:
网关可发送请求消息以启动成员资格更新周期（遵循可选的中继发现过程），以响应以下事件：
o When the gateway pseudo-interface is activated.
o 当网关伪接口被激活时。
o When the gateway wishes to report a group subscription when none currently exist.
o 当网关希望报告当前不存在的组订阅时。
Starting the membership update cycle when a gateway pseudo-interface is started provides several benefits:
在启动网关伪接口时启动成员身份更新周期可提供以下好处：
o Better performance by allowing state-change reports to be sent as they are generated, thus minimizing the time to join.
o 通过允许在生成状态更改报告时发送这些报告来提高性能，从而最大限度地减少加入时间。
o More robustness by relying on unsolicited state-change reports to update group membership state rather than the current-state reports generated by the membership update cycle. Unsolicited state-change reports are typically retransmitted multiple times while current-state reports are not.
o 通过依赖未经请求的状态更改报告来更新组成员身份状态，而不是成员身份更新周期生成的当前状态报告，增强了健壮性。未经请求的状态更改报告通常会重新传输多次，而当前状态报告则不会。
o Simplified implementation by eliminating any need to queue IGMP/ MLD messages for delivery after a Membership Query is received, since the IGMP/MLD state-change messages may be sent as they are generated.
o 由于IGMP/MLD状态更改消息可以在生成时发送，因此无需在收到成员资格查询后将IGMP/MLD消息排队以进行传递，从而简化了实现。
However, this approach places an additional load on relays, as a gateway will send periodic requests even when it has no multicast subscriptions. To reduce load on a relay, a gateway SHOULD only send a Membership Update message while it has active group subscriptions. A relay will still need to compute a Response MAC for each Request
但是，这种方法会给中继带来额外的负载，因为网关即使没有多播订阅也会定期发送请求。为了减少中继上的负载，网关应仅在具有活动组订阅时发送成员身份更新消息。中继仍然需要为每个请求计算响应MAC
but will not be required to recompute it a second time to authenticate a Membership Update message that contains no subscriptions.
但不需要再次重新计算它来验证不包含订阅的成员身份更新消息。
A gateway sends a Request message to a relay to solicit a Membership Query response and start the membership update cycle.
网关向中继发送请求消息以请求成员资格查询响应并启动成员资格更新周期。
A gateway constructs a Request message containing a Request Nonce value computed as described in Section 5.2.3.5.6. The gateway MUST set the P flag in the Request message to identify the protocol the gateway wishes the relay to use for the General Query response.
网关构造一条请求消息，其中包含按照第5.2.3.5.6节所述计算的请求Nonce值。网关必须在请求消息中设置P标志，以标识网关希望中继用于常规查询响应的协议。
A gateway MUST send a Request message using the current Relay Address and AMT port number as the destination.
网关必须使用当前中继地址和AMT端口号作为目标发送请求消息。
A gateway MUST save a copy of the Request message or save the Request Nonce and P flag values for possible retransmission and verification of a Membership Query response.
网关必须保存请求消息的副本或保存请求Nonce和P标志值，以便可能的重新传输和验证成员资格查询响应。
When a gateway sends a Request message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
当网关发送请求消息时，可能会通知它由于先前的AMT消息传输而接收到ICMP目的地不可到达消息。第5.2.3.9节描述了ICMP目标不可到达消息的处理。
A gateway MAY retransmit a Request message if it does not receive a matching Membership Query message within some timeout period. If the gateway retransmits the message multiple times, the timeout period SHOULD be adjusted to provide a random exponential back-off. The RECOMMENDED timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and a RECOMMENDED maximum_timeout of 120 seconds (which is the recommended minimum NAT mapping timeout described in [RFC4787]).
如果网关在某个超时时间内未收到匹配的成员资格查询消息，则可以重新传输请求消息。如果网关多次重新传输消息，则应调整超时时间以提供随机指数回退。建议的超时是[initial_timeout，MIN（initial_timeout*2^ retry_count，maximum_timeout）]范围内的随机值，建议的初始_超时为1秒，建议的最大_超时为120秒（这是[RFC4787]中描述的建议的最小NAT映射超时）。
If a gateway that uses relay discovery does not receive a Membership Query within a specified time period or after a specified number of retries, the gateway SHOULD stop waiting for a Membership Query message and restart relay discovery to locate another relay.
如果使用中继发现的网关在指定的时间段内或在指定的重试次数后未收到成员资格查询，则网关应停止等待成员资格查询消息，并重新启动中继发现以定位另一个中继。
When a gateway receives a Membership Query message, it must first determine whether it should accept or ignore the message. A gateway MUST ignore a Membership Query message, or the encapsulated IP datagram within it, if the message fails to satisfy any of the following requirements:
当网关收到成员资格查询消息时，它必须首先确定是接受还是忽略该消息。如果消息未能满足以下任何要求，网关必须忽略成员资格查询消息或其中的封装IP数据报：
o The gateway MUST be waiting for a Membership Query message.
o 网关必须等待成员资格查询消息。
o The Request Nonce value contained in the Membership Query MUST equal the Request Nonce value contained in the Request message.
o 成员资格查询中包含的请求Nonce值必须等于请求消息中包含的请求Nonce值。
o The source IP address and UDP port of the Membership Query MUST equal the destination IP address and UDP port of the matching Request message (i.e., the current Relay Address).
o 成员资格查询的源IP地址和UDP端口必须等于匹配请求消息的目标IP地址和UDP端口（即当前中继地址）。
o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 message. The protocol MUST match the protocol identified by the P flag in the Request message.
o 封装的IP数据报必须携带IGMPv3或MLDv2消息。协议必须与请求消息中的P标志标识的协议匹配。
o The IGMPv3 or MLDv2 message MUST be a General Query message.
o IGMPv3或MLDv2消息必须是常规查询消息。
o The total length of the encapsulated IP datagram as computed from the lengths contained in the datagram header(s) MUST NOT exceed the available field length within the Membership Query message.
o 根据数据报报头中包含的长度计算的封装IP数据报的总长度不得超过成员资格查询消息中的可用字段长度。
Once a gateway receives a Membership Query response to a Request message, it SHOULD ignore any other Membership Query messages that arrive on the AMT interface until it sends a new Request message.
一旦网关收到对请求消息的成员资格查询响应，它应该忽略到达AMT接口的任何其他成员资格查询消息，直到它发送新的请求消息。
The gateway MUST save the Membership Query message, or the Request Nonce, Response MAC, Gateway IP Address, and Gateway Port Number fields for use in sending subsequent Membership Update and Teardown messages.
网关必须保存成员资格查询消息，或请求Nonce、响应MAC、网关IP地址和网关端口号字段，以便在发送后续成员资格更新和拆卸消息时使用。
The gateway extracts the encapsulated IP datagram and forwards it to the local IP protocol implementation for checksum verification and dispatching to the IGMP or MLD implementation running on the pseudo-interface. The gateway MUST NOT forward any octets that might exist between the encapsulated IP datagram and the end of the message or Gateway Address fields.
网关提取封装的IP数据报，并将其转发给本地IP协议实现，以进行校验和验证，并将其分派给在伪接口上运行的IGMP或MLD实现。网关不得转发封装的IP数据报和消息结尾或网关地址字段之间可能存在的任何八位字节。
The MLD protocol specification indicates that senders should use a link-local source IP address in message datagrams. This requirement must be relaxed for AMT because gateways and relays do not normally share a common subnet. For this reason, a gateway implementation MUST accept MLD (and IGMP) query message datagrams regardless of the
MLD协议规范指出发送方应在消息数据报中使用链路本地源IP地址。AMT必须放宽这一要求，因为网关和中继通常不共享公共子网。因此，网关实现必须接受MLD（和IGMP）查询消息数据报，而不考虑
source IP address they carry. This may require additional processing on the part of the gateway that might be avoided if the relay and gateway use the IPv4 and IPv6 addresses allocated for use in AMT-encapsulated control packets as described in Section 5.2.1.
他们携带的源IP地址。如果中继和网关使用分配用于AMT封装控制数据包的IPv4和IPv6地址（如第5.2.1节所述），这可能需要网关部分进行额外处理。
The gateway MUST start a timer that will trigger the next iteration of the membership update cycle by executing the membership query procedure. The gateway SHOULD compute the timer duration from the Querier's Query Interval Code carried by the General Query. A gateway MAY use a smaller timer duration if required to refresh a NAT mapping that would otherwise time out. A gateway MAY use a larger timer duration if it has no group subscriptions to report.
网关必须启动计时器，通过执行成员资格查询过程触发成员资格更新周期的下一次迭代。网关应根据一般查询携带的查询器查询间隔代码计算计时器持续时间。如果需要刷新否则会超时的NAT映射，网关可以使用较小的计时器持续时间。如果网关没有要报告的组订阅，则可能会使用更大的计时器持续时间。
If the gateway supports the Teardown message and the G flag is set in the Membership Query message, the gateway MUST compare the Gateway IP Address and Gateway Port Number on the new Membership Query message with the values carried by the previous Membership Query message. If either value has changed, the gateway MUST send a Teardown message to the relay as described in Section 5.2.3.7.
如果网关支持拆卸消息，并且在成员资格查询消息中设置了G标志，则网关必须将新成员资格查询消息上的网关IP地址和网关端口号与前一个成员资格查询消息中携带的值进行比较。如果任一值发生变化，网关必须按照第5.2.3.7节所述向继电器发送拆卸消息。
If the L flag is set in the Membership Query message, the relay is reporting that it is NOT accepting Membership Update messages that create new tunnel endpoints and will simply ignore any that do. If the L flag is set and the gateway is not currently reporting any group subscriptions to the relay, the gateway SHOULD stop sending periodic Request messages and restart the relay discovery procedure (if discovery is enabled) to find a new relay with which to communicate. Even if the L flag is set, the gateway MAY continue to send updates if it has previously reported group subscriptions to the relay, one or more subscriptions still exist, and the gateway endpoint address has not changed since the last Membership Query was received (see previous paragraph).
如果在成员资格查询消息中设置了L标志，则中继将报告它不接受创建新隧道端点的成员资格更新消息，并且将忽略任何这样做的消息。如果设置了L标志，并且网关当前未向中继报告任何组订阅，则网关应停止发送定期请求消息，并重新启动中继发现过程（如果启用了发现），以查找要与之通信的新中继。即使设置了L标志，如果网关以前向中继报告过组订阅，一个或多个订阅仍然存在，并且自收到上一次成员资格查询以来网关端点地址没有更改，则网关也可以继续发送更新（请参见上一段）。
When the query timer (started in the previous step) expires, the gateway should execute the membership query procedure again to continue the membership update cycle.
当查询计时器（在上一步中启动）过期时，网关应再次执行成员资格查询过程以继续成员资格更新周期。
The Request Nonce MUST be a random value and, if possible, SHOULD be computed using a cryptographically secure pseudorandom number generator. A new nonce MUST be generated each time the gateway starts the membership query process. The same nonce SHOULD be used when retransmitting a Request message.
请求Nonce必须是一个随机值，如果可能，应该使用加密安全的伪随机数生成器计算。每次网关启动成员资格查询过程时，都必须生成新的nonce。在重新传输请求消息时，应使用相同的nonce。
This section describes gateway requirements related to the membership update message sequence described in Section 4.2.1.2.
本节描述了与第4.2.1.2节所述成员资格更新消息序列相关的网关要求。
The membership update process is primarily driven by the host-mode IGMP or MLD protocol implementation running on the gateway pseudo-interface. The IGMP and MLD protocols produce current-state reports in response to General Query messages generated by the pseudo-interface via AMT and produce state-change reports in response to receiver requests made using the IGMP or MLD service interface.
成员资格更新过程主要由运行在网关伪接口上的主机模式IGMP或MLD协议实现驱动。IGMP和MLD协议生成当前状态报告，以响应伪接口通过AMT生成的一般查询消息，并生成状态更改报告，以响应使用IGMP或MLD服务接口发出的接收器请求。
The gateway pseudo-interface MUST accept the following IP datagrams from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo-interface:
网关伪接口必须接受来自在伪接口上运行的IPv4/IGMP和IPv6/MLD协议的以下IP数据报：
o IPv4 datagrams that carry an IGMPv2 or IGMPv3 Membership Report or an IGMPv2 Leave Group message as described in Section 4 of [RFC3376].
o 如[RFC3376]第4节所述，携带IGMPv2或IGMPv3成员报告或IGMPv2的IPv4数据报离开组消息。
o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener Report or an MLDv1 Multicast Listener Done message as described in Section 5 of [RFC3810].
o 携带MLDv1或MLDv2多播侦听器报告或MLDv1多播侦听器完成消息的IPv6数据报，如[RFC3810]第5节所述。
The gateway must be prepared to receive these messages any time the pseudo-interface is running. The gateway MUST ignore any datagrams not listed above.
网关必须准备好在伪接口运行时随时接收这些消息。网关必须忽略上面未列出的任何数据报。
A gateway that waits to start a membership update cycle until after it receives a datagram containing an IGMP/MLD state-change message MAY:
在收到包含IGMP/MLD状态更改消息的数据报之前等待启动成员资格更新周期的网关可能：
o Discard IGMP or MLD datagrams until it receives a Membership Query message, at which time it processes the Membership Query message as normal to eventually produce a current-state report on the pseudo-interface, which describes the end state (RECOMMENDED).
o 丢弃IGMP或MLD数据报，直到收到成员资格查询消息为止，此时它将正常处理成员资格查询消息，以最终在伪接口上生成一个描述结束状态的当前状态报告（推荐）。
o Insert IGMP or MLD datagrams into a queue for transmission after it receives a Membership Query message.
o 在接收到成员资格查询消息后，将IGMP或MLD数据报插入队列进行传输。
If and when a gateway receives a Membership Query message (for IGMP or MLD), it sends any queued or incoming IGMP or MLD datagrams to the relay as described in the next section.
如果且当网关接收到成员资格查询消息（针对IGMP或MLD），它将向中继器发送任何排队或传入的IGMP或MLD数据报，如下一节所述。
A gateway cannot send a Membership Update message to a relay until it has received a Membership Query message from a relay. If the gateway has not yet located a relay with which to communicate, it MUST first execute the relay discovery procedure described in Section 5.2.3.4 to obtain a Relay Address. If the gateway has a Relay Address but has not yet received a Membership Query message, it MUST first execute the membership query procedure described in Section 5.2.3.5 to obtain a Request Nonce and Response MAC that can be used to send a Membership Update message.
网关在收到来自中继的成员资格查询消息之前，无法向中继发送成员资格更新消息。如果网关尚未找到与之通信的继电器，则必须首先执行第5.2.3.4节中描述的继电器发现程序，以获得继电器地址。如果网关具有中继地址，但尚未收到成员资格查询消息，则必须首先执行第5.2.3.5节中描述的成员资格查询过程，以获得可用于发送成员资格更新消息的请求Nonce和响应MAC。
Once a gateway possesses a valid Relay Address, Request Nonce, and Response MAC, it may encapsulate the IP datagram containing the IGMP/ MLD message into a Membership Update message. The gateway MUST copy the Request Nonce and Response MAC values from the last Membership Query received from the relay into the corresponding fields in the Membership Update. The gateway MUST send the Membership Update message using the Relay Address and AMT port number as the destination.
一旦网关拥有有效的中继地址、请求Nonce和响应MAC，它就可以将包含IGMP/MLD消息的IP数据报封装到成员身份更新消息中。网关必须将从中继接收到的最后一个成员资格查询中的请求Nonce和响应MAC值复制到成员资格更新中的相应字段中。网关必须使用中继地址和AMT端口号作为目标发送成员资格更新消息。
When a gateway sends a Membership Update message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
当网关发送成员资格更新消息时，可能会通知它由于先前的AMT消息传输而接收到ICMP目的地不可访问消息。第5.2.3.9节描述了ICMP目标不可到达消息的处理。
This section describes gateway requirements related to the teardown message sequence described in Section 4.2.1.3.
本节描述了与第4.2.1.3节所述拆卸消息序列相关的网关要求。
Gateway support for the Teardown message is RECOMMENDED.
建议对拆卸消息提供网关支持。
A gateway that supports Teardown SHOULD make use of Teardown functionality if it receives a Membership Query message from a relay that has the G flag set to indicate that it contains valid Gateway Address fields.
如果支持拆卸的网关从设置了G标志的中继接收到成员资格查询消息，表明其包含有效的网关地址字段，则应使用拆卸功能。
As described in Section 5.2.3.5.4, if a gateway supports the Teardown message, has reported active group subscriptions, and receives a Membership Query message with the G flag set, the gateway MUST compare the Gateway IP Address and Gateway Port Number on the new Membership Query message with the values carried by the previous Membership Query message. If either value has changed, the gateway MUST send a Teardown message as described in the next section.
如第5.2.3.5.4节所述，如果网关支持拆卸消息，已报告活动组订阅，并收到设置了G标志的成员资格查询消息，网关必须将新成员资格查询消息上的网关IP地址和网关端口号与前一个成员资格查询消息中的值进行比较。如果任意一个值已更改，网关必须发送一条拆卸消息，如下一节所述。
A gateway sends a Teardown message to a relay to request that it stop delivering Multicast Data messages to the gateway and delete any group memberships created by the gateway.
网关向中继器发送拆卸消息，请求它停止向网关发送多播数据消息，并删除由网关创建的任何组成员身份。
When a gateway constructs a Teardown message, it MUST copy the Request Nonce, Response MAC, Gateway IP Address, and Gateway Port Number fields from the Membership Query message that provided the Response MAC for the last Membership Update message sent, into the corresponding fields of the Teardown message.
当网关构造拆卸消息时，它必须将为上次发送的成员资格更新消息提供响应MAC的成员资格查询消息中的请求Nonce、响应MAC、网关IP地址和网关端口号字段复制到拆卸消息的相应字段中。
A gateway MUST send the Teardown message using the Relay Address and AMT port number as the destination. A gateway MAY send the Teardown message multiple times for robustness. The gateway SHOULD use the Querier's Robustness Variable (QRV) field contained in the query encapsulated within the last Membership Query to set the limit on the number of retransmissions (see Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810]). If the gateway sends the Teardown message multiple times, it SHOULD insert a delay between each transmission using the timing algorithm employed in IGMP/MLD for transmitting unsolicited state-change reports. The RECOMMENDED default delay value is 1 second.
网关必须使用中继地址和AMT端口号作为目标发送拆卸消息。网关可以多次发送拆卸消息，以增强健壮性。网关应使用上次成员资格查询中封装的查询中包含的查询器鲁棒性变量（QRV）字段来设置重传次数限制（参见[RFC3376]第4.1.6节和[RFC3810]第5.1.8节）。如果网关多次发送拆卸消息，则应使用IGMP/MLD中用于传输未经请求的状态更改报告的定时算法在每次传输之间插入延迟。建议的默认延迟值为1秒。
When a gateway sends a Teardown message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9.
当网关发送拆卸消息时，可能会通知它，由于先前的AMT消息传输，接收到ICMP目标不可到达消息。第5.2.3.9节描述了ICMP目标不可到达消息的处理。
When a gateway pseudo-interface is stopped and the gateway has existing group subscriptions, the gateway SHOULD either:
当网关伪接口停止且网关具有现有组订阅时，网关应：
o Send a Teardown message to the relay as described in Section 5.2.3.7, but only if the gateway supports the Teardown message and the current relay is returning Gateway Address fields in Membership Query messages, or
o 如第5.2.3.7节所述，向中继发送拆卸消息，但仅当网关支持拆卸消息且当前中继正在成员查询消息中返回网关地址字段时，或
o Send a Membership Update message to the relay that will delete existing group subscriptions.
o 向将删除现有组订阅的中继发送成员资格更新消息。
A gateway may receive an ICMP Destination Unreachable message [RFC0792] after sending an AMT message. Whether the gateway is notified that an ICMP message was received is highly dependent on firewall and gateway IP stack behavior and gateway implementation.
网关在发送AMT消息后可能会收到ICMP目的地不可访问消息[RFC0792]。网关是否收到收到ICMP消息的通知在很大程度上取决于防火墙和网关IP堆栈行为以及网关实现。
If the reception of an ICMP Destination Unreachable message is reported to the gateway while waiting to receive an AMT message, the gateway may respond as follows, depending on platform capabilities and which outgoing message triggered the ICMP response:
如果在等待接收AMT消息时向网关报告接收到ICMP目的地不可到达消息，则网关可根据平台能力和触发ICMP响应的传出消息做出如下响应：
1. The gateway MAY simply abandon the current relay and restart relay discovery (if used). This is the least desirable approach, as it does not allow for transient network changes.
1. 网关可以简单地放弃当前中继并重新启动中继发现（如果使用）。这是最不理想的方法，因为它不允许瞬时网络变化。
2. If the last message sent was a Relay Discovery or Request message, the gateway MAY simply ignore the ICMP response and continue waiting for incoming AMT messages. If the gateway is configured to retransmit Relay Discovery or Request messages, the normal retransmission behavior for those messages is preserved to prevent the gateway from prematurely abandoning a relay.
2. 如果发送的最后一条消息是中继发现或请求消息，网关可能会忽略ICMP响应并继续等待传入的AMT消息。如果网关配置为重新传输中继发现或请求消息，则会保留这些消息的正常重新传输行为，以防止网关过早放弃中继。
3. If the last message sent was a Membership Update message, the gateway MAY start a new membership update and associated Request retransmission cycle.
3. 如果发送的最后一条消息是成员资格更新消息，则网关可以开始新的成员资格更新和相关的请求重传周期。
If the reception of an ICMP Destination Unreachable message is reported to the gateway when attempting to transmit a new AMT message, the gateway may respond as follows, depending on platform capabilities and which outgoing message triggered the ICMP response:
如果在尝试传输新AMT消息时向网关报告接收到ICMP目的地不可到达消息，则网关可能会根据平台能力和触发ICMP响应的传出消息做出如下响应：
1. The gateway MAY simply abandon the current relay and restart relay discovery (if used). This is the least desirable approach, as it does not allow for transient network changes.
1. 网关可以简单地放弃当前中继并重新启动中继发现（如果使用）。这是最不理想的方法，因为它不允许瞬时网络变化。
2. If the last message sent was a Relay Discovery, Request, or Teardown message, the gateway MAY attempt to transmit the new message. If the gateway is configured to retransmit Relay Discovery, Request, or Teardown messages, the normal retransmission behavior for those messages is preserved to prevent the gateway from prematurely abandoning a relay.
2. 如果发送的最后一条消息是中继发现、请求或拆卸消息，网关可能会尝试发送新消息。如果网关配置为重新传输中继发现、请求或拆卸消息，则这些消息的正常重新传输行为将被保留，以防止网关过早放弃中继。
3. If the last message sent was a Membership Update message, the gateway SHOULD start a new membership update and associated Request retransmission cycle.
3. 如果发送的最后一条消息是成员身份更新消息，则网关应启动新的成员身份更新和相关的请求重传周期。
The following sections describe relay implementation requirements. A non-normative discussion of relay operation may be found in Section 4.2.
以下各节描述了继电器的实施要求。关于继电器操作的非规范性讨论见第4.2节。
A relay requires a subset of router-mode IGMP and MLD functionality to provide group membership tracking and report processing.
中继需要路由器模式IGMP和MLD功能的子集，以提供组成员跟踪和报告处理。
A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and MAY support IPv4/IGMPv3.
通过IPv4访问的中继必须支持IPv4/IGMPv3，并且可能支持IPv6/MLDv2。可通过IPv6访问的中继必须支持IPv6/MLDv2，并且可能支持IPv4/IGMPv3。
A relay MUST apply the forwarding rules described in Section 6.3 of [RFC3376] and Section 7.3 of [RFC3810].
中继必须应用[RFC3376]第6.3节和[RFC3810]第7.3节中所述的转发规则。
A relay MUST handle incoming reports as described in Section 6.4 of [RFC3376] and Section 7.4 of [RFC3810], with the exception that actions that lead to queries MAY be modified to eliminate query generation. A relay MUST accept IGMP and MLD report datagrams regardless of the IP source address carried by those datagrams.
中继必须按照[RFC3376]第6.4节和[RFC3810]第7.4节所述处理传入报告，但导致查询的操作可能会被修改以消除查询生成。中继必须接受IGMP和MLD报告数据报，而不管这些数据报携带的IP源地址。
All other aspects of IGMP/MLD router behavior, such as the handling of queries, querier election, etc., are not used or required for relay operation.
IGMP/MLD路由器行为的所有其他方面，例如查询处理、查询器选择等，都不用于或不需要用于中继操作。
If a relay is deployed for anycast discovery, the relay MUST advertise an anycast Relay Discovery Address Prefix into the unicast routing system of the anycast domain. An address within that prefix, i.e., a Relay Discovery Address, MUST be assigned to a relay interface.
如果为选播发现部署了中继，则中继必须将选播中继发现地址前缀播发到选播域的单播路由系统中。该前缀内的地址，即中继发现地址，必须分配给中继接口。
A unicast IPv4 and/or IPv6 address MUST be assigned to the relay interface that will be used to send and receive AMT control and data messages. This address or addresses are returned in Relay Advertisement messages.
必须将单播IPv4和/或IPv6地址分配给将用于发送和接收AMT控制和数据消息的中继接口。此地址或多个地址在中继播发消息中返回。
The remaining details of relay "startup" are highly implementation dependent and are not addressed in this document.
中继“启动”的其余细节高度依赖于实现，本文档中未涉及。
When a relay is started, it begins listening for AMT messages on the interface to which the unicast Relay Address(es) has been assigned, i.e., the address returned in Relay Advertisement messages.
当中继启动时，它开始在已分配单播中继地址（即中继播发消息中返回的地址）的接口上侦听AMT消息。
A relay MUST ignore any message other than a Relay Discovery, Request, Membership Update, or Teardown message. The handling of Relay Discovery, Request, Membership Update, and Teardown messages is addressed in the sections that follow.
中继必须忽略中继发现、请求、成员身份更新或拆卸消息以外的任何消息。中继发现、请求、成员资格更新和拆卸消息的处理将在下面的部分中介绍。
Support for the Teardown message is OPTIONAL. If a relay does not support the Teardown message, it MUST also ignore this message.
对拆卸消息的支持是可选的。如果继电器不支持拆卸消息，它也必须忽略此消息。
A relay that conforms to this specification MUST ignore any message with a Version field value other than zero.
符合本规范的继电器必须忽略版本字段值不是零的任何消息。
This section describes relay requirements related to the relay discovery message sequence described in Section 4.2.1.1.
本节描述了与第4.2.1.1节中描述的中继发现消息序列相关的中继要求。
A relay MUST accept and respond to Relay Discovery messages sent to an anycast Relay Discovery Address or the unicast Relay Address. If a relay receives a Relay Discovery message sent to its unicast address, it MUST respond just as it would if the message had been sent to its anycast Relay Discovery Address.
中继必须接受并响应发送到选播中继发现地址或单播中继地址的中继发现消息。如果中继接收到发送到其单播地址的中继发现消息，它必须像发送到其选播中继发现地址的消息一样进行响应。
When a relay receives a Relay Discovery message, it responds by sending a Relay Advertisement message back to the source of the Relay Discovery message.
当中继接收到中继发现消息时，它通过将中继广告消息发送回中继发现消息的源来响应。
The relay MUST use the source IP address and UDP port number of the Relay Discovery message as the destination IP address and UDP port number for the Relay Advertisement message. The source IP address and UDP port number carried by the Relay Advertisement message MUST match the destination IP address and UDP port number of the Relay Discovery message to ensure successful NAT traversal.
中继必须使用中继发现消息的源IP地址和UDP端口号作为中继播发消息的目标IP地址和UDP端口号。中继播发消息携带的源IP地址和UDP端口号必须与中继发现消息的目标IP地址和UDP端口号匹配，以确保NAT穿越成功。
The relay MUST copy the value contained in the Discovery Nonce field of the Relay Discovery message into the Discovery Nonce field in the Relay Advertisement message.
中继必须将中继发现消息的Discovery Nonce字段中包含的值复制到中继播发消息的Discovery Nonce字段中。
If the Relay Discovery message was received as an IPv4 datagram, the relay MUST return an IPv4 address in the Relay Address field of the Relay Advertisement message. If the Relay Discovery message was received as an IPv6 datagram, the relay MUST return an IPv6 address in the Relay Address field.
如果中继发现消息作为IPv4数据报接收，则中继必须在中继播发消息的中继地址字段中返回IPv4地址。如果中继发现消息作为IPv6数据报接收，则中继必须在中继地址字段中返回IPv6地址。
This section describes relay requirements related to the membership query portion of the message sequence described in Section 4.2.1.2.
本节描述了与第4.2.1.2节所述消息序列的成员资格查询部分相关的中继要求。
When a relay receives a Request message, it responds by sending a Membership Query message back to the source of the Request message.
当中继接收到请求消息时，它通过将成员资格查询消息发送回请求消息的源来响应。
The relay MUST use the source IP address and UDP port of the Request message as the destination IP address and UDP port for the Membership Query message. The source IP address and UDP port carried by the Membership Query MUST match the destination IP address and UDP port of the Request to ensure successful NAT traversal.
中继必须使用请求消息的源IP地址和UDP端口作为成员资格查询消息的目标IP地址和UDP端口。成员资格查询携带的源IP地址和UDP端口必须与请求的目标IP地址和UDP端口匹配，以确保NAT穿越成功。
The relay MUST return the value contained in the Request Nonce field of the Request message in the Request Nonce field of the Membership Query message. The relay MUST compute a MAC value, as described in Section 5.3.5, and return that value in the Response MAC field of the Membership Query message.
中继必须在成员资格查询消息的请求Nonce字段中返回请求消息的请求Nonce字段中包含的值。中继必须计算MAC值，如第5.3.5节所述，并在成员资格查询消息的响应MAC字段中返回该值。
If a relay supports the Teardown message, it MUST set the G flag in the Membership Query message and return the source IP address and UDP port carried by the Request message in the corresponding Gateway IP Address and Gateway Port Number fields. If the relay does not support the Teardown message, it SHOULD NOT set these fields, as this may cause the gateway to generate unnecessary Teardown messages.
如果中继支持拆卸消息，则必须在成员资格查询消息中设置G标志，并在相应的网关IP地址和网关端口号字段中返回请求消息携带的源IP地址和UDP端口。如果中继不支持拆卸消息，则不应设置这些字段，因为这可能会导致网关生成不必要的拆卸消息。
If the P flag in the Request message is 0, the relay MUST return an IPv4-encapsulated IGMPv3 General Query in the Membership Query message. If the P flag is 1, the relay MUST return an IPv6-encapsulated MLDv2 General Query in the Membership Query message.
如果请求消息中的P标志为0，则中继必须在成员资格查询消息中返回IPv4封装的IGMPv3常规查询。如果P标志为1，则中继必须在成员资格查询消息中返回IPv6封装的MLDv2常规查询。
If the relay is not accepting Membership Update messages that create new tunnel endpoints due to resource limitations, it SHOULD set the L flag in the Membership Query message to notify the gateway of this state. Support for the L flag is OPTIONAL. See Section 5.3.3.8.
如果由于资源限制，中继不接受创建新隧道端点的成员身份更新消息，则应在成员身份查询消息中设置L标志以通知网关此状态。对L标志的支持是可选的。见第5.3.3.8节。
The encapsulated IGMPv3 General Query datagrams generated by a relay MUST conform to the descriptions found in Section 4.1 of [RFC3376]. These datagrams MUST possess the IP headers, header options, and header values called for in [RFC3376], with the following exception: a relay MAY use any source IP address for an IGMP General Query datagram, including the "unspecified" address (all octets are zero). This exception is made because any source address that a relay might normally send may not be a valid link-local address on any gateway interface. It is for this reason that a gateway must accept encapsulated IGMP queries regardless of the source address they carry. See Section 5.2.1.
中继生成的封装IGMPv3通用查询数据报必须符合[RFC3376]第4.1节中的描述。这些数据报必须具有[RFC3376]中要求的IP报头、报头选项和报头值，但以下情况除外：中继可以使用IGMP通用查询数据报的任何源IP地址，包括“未指定”地址（所有八位字节均为零）。之所以出现此异常，是因为中继正常发送的任何源地址都可能不是任何网关接口上的有效链路本地地址。正是由于这个原因，网关必须接受封装的IGMP查询，而不管它们携带的源地址如何。见第5.2.1节。
The encapsulated MLDv2 General Query datagrams generated by a relay MUST conform to the descriptions found in Section 5.1 of [RFC3810]. These datagrams MUST possess the IP headers, header options, and header values called for in [RFC3810], with the following exception: a relay MAY use any source IP address for an MLD General Query datagram, including the "unspecified" address (all octets are zero). This exception is made because any source address that a relay might normally send may not be a valid link-local address on any gateway interface. As with IGMP, it is for this reason that a gateway must accept encapsulated MLD queries regardless of the source address they carry. See Section 5.2.1.
中继生成的封装MLDv2通用查询数据报必须符合[RFC3810]第5.1节中的描述。这些数据报必须具有[RFC3810]中要求的IP报头、报头选项和报头值，但以下情况除外：中继可以使用MLD通用查询数据报的任何源IP地址，包括“未指定”地址（所有八位字节均为零）。之所以出现此异常，是因为中继正常发送的任何源地址都可能不是任何网关接口上的有效链路本地地址。与IGMP一样，正是由于这个原因，网关必须接受封装的MLD查询，而不管它们携带的源地址如何。见第5.2.1节。
A relay MUST set the Querier's Query Interval Code (QQIC) field in the General Query to supply the gateway with a suggested time duration to use for the membership query timer. The QQIC field is defined in Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]. A relay MAY adjust this value to affect the rate at which the Request messages are sent from a gateway. However, a gateway is allowed to use a shorter duration than the duration specified in the QQIC field, so a relay may be limited in its ability to spread out Requests coming from a gateway.
中继必须在常规查询中设置查询者的查询间隔代码（QQIC）字段，以便为网关提供用于成员查询计时器的建议持续时间。[RFC3376]第4.1.7节和[RFC3810]第5.1.9节定义了QQIC字段。中继可以调整该值，以影响从网关发送请求消息的速率。但是，允许网关使用比QQIC字段中指定的持续时间更短的持续时间，因此中继可能会限制其分散来自网关的请求的能力。
A relay MUST set the Querier's Robustness Variable (QRV) field in the General Query to a non-zero value. This value SHOULD be greater than one. If a gateway retransmits membership state-change messages, it will retransmit them (Robustness Variable - 1) times. The QRV field is defined in Section 4.1.6 of [RFC3376] and Section 5.1.8 of [RFC3810].
中继必须在常规查询中将查询器的稳健性变量（QRV）字段设置为非零值。此值应大于1。如果网关重新传输成员状态更改消息，它将重新传输它们（健壮性变量-1）次。QRV字段在[RFC3376]第4.1.6节和[RFC3810]第5.1.8节中定义。
A relay SHOULD set the Maximum Response Code field in the General Query to a value of 1 to trigger an immediate response from the gateway (some host IGMP/MLD implementations may not accept a value of zero). A relay SHOULD NOT use the IGMPv3/MLDv2 Query Response Interval variable, if available, to generate the Maximum Response Code field value, as the Query Response Interval variable is used in setting the duration of group state timers and must not be set to
中继应将常规查询中的最大响应代码字段设置为值1，以触发来自网关的即时响应（某些主机IGMP/MLD实现可能不接受值零）。中继不应使用IGMPv3/MLDv2查询响应间隔变量（如果可用）来生成最大响应代码字段值，因为查询响应间隔变量用于设置组状态计时器的持续时间，且不得设置为
such a small value. The Maximum Response Code field is defined in Section 4.1.1 of [RFC3376] and Section 5.1.3 of [RFC3810]. See Section 5.3.3.7.
这么小的价值。[RFC3376]第4.1.1节和[RFC3810]第5.1.3节定义了最大响应代码字段。见第5.3.3.7节。
This section describes relay requirements related to the membership update portion of the message sequence described in Section 4.2.1.2.
本节描述了与第4.2.1.2节所述消息序列的成员资格更新部分相关的中继要求。
When a relay receives a Membership Update message, it must first determine whether it should accept or ignore the message. A relay MUST NOT make any changes to group membership and forwarding state if the message fails to satisfy any of the following requirements:
当中继接收到成员资格更新消息时，它必须首先确定是接受还是忽略该消息。如果消息未能满足以下任何要求，则中继不得对组成员身份和转发状态进行任何更改：
o The IP datagram encapsulated within the message MUST be one of the following:
o 封装在消息中的IP数据报必须是以下之一：
* IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report message.
* 携带IGMPv2或IGMPv3成员资格报告消息的IPv4数据报。
* IPv4 datagram carrying an IGMPv2 Leave Group message.
* 携带IGMPv2离开组消息的IPv4数据报。
* IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener Report message.
* 携带MLDv1或MLDv2多播侦听器报告消息的IPv6数据报。
* IPv6 datagram carrying MLDv1 Multicast Listener Done message.
* 携带MLDv1多播侦听器完成消息的IPv6数据报。
o The encapsulated IP datagram MUST satisfy the IP header requirements for the IGMP or MLD message type as described in Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of [RFC3810], and Section 3 of [RFC2710], with the following exception: a relay MUST accept an IGMP or MLD message regardless of the IP source address carried by the datagram.
o 封装的IP数据报必须满足[RFC3376]第4节、[RFC2236]第2节、[RFC3810]第5节和[RFC2710]第3节中所述的IGMP或MLD消息类型的IP报头要求，除了以下例外：无论数据报携带的IP源地址如何，中继都必须接受IGMP或MLD消息。
o The total length of the encapsulated IP datagram as computed from the lengths contained in the datagram header(s) MUST NOT exceed the available field length within the Membership Update message.
o 根据数据报报头中包含的长度计算的封装IP数据报的总长度不得超过成员资格更新消息中的可用字段长度。
o The computed checksums for the encapsulated IP datagram and its payload MUST match the values contained therein. Checksum computation and verification vary by protocol; see [RFC0791] for IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).
o 封装的IP数据报及其有效负载的计算校验和必须与其中包含的值匹配。校验和计算和验证因协议而异；IPv4请参见[RFC0791]，IGMPv3请参见[RFC3376]，MLD（ICMPv6）请参见[RFC4443]。
o If processing of the encapsulated IGMP or MLD message would result in an allocation of new state or a modification of existing state, the relay MUST authenticate the source of the message by verifying that the value contained in the Response MAC field equals the MAC value computed from the fields in the Membership Update message
o 如果对封装的IGMP或MLD消息的处理将导致新状态的分配或现有状态的修改，则中继必须通过验证响应MAC字段中包含的值等于根据成员资格更新消息中的字段计算的MAC值来验证消息源
datagram. If a time-varying private secret is used in the computation of a Response MAC, the relay MUST retain the previous version of the private secret for use in authenticating Membership Updates sent during the subsequent query interval. If the first attempt at Response MAC authentication fails, the relay MUST attempt to authenticate the Response MAC using the previous private secret value unless 2 * query_interval time has elapsed since the private secret change. See Section 5.3.5.
数据报。如果在响应MAC的计算中使用时变私有秘密，则中继必须保留该私有秘密的先前版本，以用于认证在随后的查询间隔期间发送的成员身份更新。如果响应MAC身份验证的第一次尝试失败，则中继必须尝试使用先前的私有机密值对响应MAC进行身份验证，除非自私有机密更改以来已过2*query\u间隔时间。见第5.3.5节。
A relay MAY skip source authentication to reduce the computational cost of handling Membership Update messages if the relay can make a trivial determination that the IGMP/MLD message carried by the Membership Update message will produce no changes in group membership or forwarding state. The relay does not need to compute and compare MAC values if it finds there are no group subscriptions for the source of the Membership Update message and either of the following is true:
如果中继器可以简单地确定由成员资格更新消息携带的IGMP/MLD消息将不会在组成员资格或转发状态中产生变化，则中继器可以跳过源认证以减少处理成员资格更新消息的计算成本。如果中继发现成员身份更新消息的源没有组订阅，并且以下任一项为真，则无需计算和比较MAC值：
o The encapsulated IP datagram is an IGMPv3 Membership Report or MLDv2 Multicast Listener Report message that contains no group records. This may often be the case for gateways that continuously repeat the membership update cycle even though they have no group subscriptions to report.
o 封装的IP数据报是不包含组记录的IGMPv3成员资格报告或MLDv2多播侦听器报告消息。对于连续重复成员身份更新周期的网关，即使它们没有要报告的组订阅，也可能经常出现这种情况。
o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 Multicast Listener Done message.
o 封装的IP数据报是IGMPv2离开组或MLDv1多播侦听器完成消息。
The IGMP and MLD protocol specifications indicate that senders SHOULD use a link-local source IP address in message datagrams. This requirement must be relaxed for AMT because gateways and relays do not share a common subnet. For this reason, a relay implementation MUST accept IGMP and MLD datagrams regardless of the source IP address they carry.
IGMP和MLD协议规范指出，发送方应在消息数据报中使用链路本地源IP地址。AMT必须放宽这一要求，因为网关和中继不共享一个子网。因此，中继实现必须接受IGMP和MLD数据报，而不管它们携带的源IP地址如何。
Once a relay has determined that the Membership Update message is valid, it processes the encapsulated IGMP or MLD message to update group membership state and communicates with the multicast protocol to update forwarding state and possibly send multicast protocol messages towards upstream routers. The relay MUST ignore any octets that might exist between the encapsulated IP datagram and the end of the Membership Update message.
一旦中继器确定成员身份更新消息有效，它处理封装的IGMP或MLD消息以更新组成员身份状态，并与多播协议通信以更新转发状态，并且可能向上游路由器发送多播协议消息。中继必须忽略封装的IP数据报和成员身份更新消息结尾之间可能存在的任何八位字节。
As described in Section 4.2.2, a relay uses the source IP address and source UDP port carried by a Membership Update message to identify a tunnel endpoint. A relay uses the tunnel endpoint as the destination address for any Multicast Data messages it sends as a result of the
如第4.2.2节所述，中继使用成员身份更新消息携带的源IP地址和源UDP端口来标识隧道端点。中继使用隧道端点作为其作为传输结果发送的任何多播数据消息的目标地址
group membership and forwarding state created by processing the IGMP/ MLD messages contained in Membership Update messages received from the endpoint.
通过处理从端点接收的成员资格更新消息中包含的IGMP/MLD消息而创建的组成员资格和转发状态。
If a Membership Update message originates from a new endpoint, the relay MUST determine whether it can accept updates from a new endpoint. If a relay has been configured with a limit on the total number of endpoints, or a limit on the total number of endpoints for a given source address, then the relay MAY ignore the Membership Update message and possibly withdraw any Relay Discovery Address Prefix announcement that it might have made. See Section 5.3.3.8.
如果成员身份更新消息源自新端点，则中继必须确定是否可以接受来自新端点的更新。如果已为中继配置了对端点总数的限制，或对给定源地址的端点总数的限制，则该中继可能会忽略成员身份更新消息，并可能会撤回其可能已做出的任何中继发现地址前缀声明。见第5.3.3.8节。
A relay MUST maintain some form of group membership database for each endpoint. The per-endpoint databases are used to update a forwarding table containing entries that map a (*,G) or (S,G) subscription to a list of tunnel endpoints.
中继必须为每个端点维护某种形式的组成员数据库。每端点数据库用于更新转发表，其中包含将（*，G）或（S，G）订阅映射到隧道端点列表的条目。
A relay MUST maintain some form of group membership database representing a merger of the group membership databases of all endpoints. The merged group membership database is used to update upstream multicast forwarding state.
中继必须维护某种形式的组成员数据库，表示所有端点的组成员数据库的合并。合并的组成员数据库用于更新上游多播转发状态。
A relay MUST maintain a forwarding table that maps each unique (*,G) and (S,G) subscription to a list of tunnel endpoints. A relay uses this forwarding table to provide the destination address when performing UDP/IP encapsulation of the incoming multicast IP datagrams to form Multicast Data messages.
中继必须维护一个转发表，该表将每个唯一（*，G）和（S，G）订阅映射到隧道端点列表。中继在对传入的多播IP数据报执行UDP/IP封装以形成多播数据消息时，使用此转发表提供目标地址。
If a group filter mode for a group entry on a tunnel endpoint is EXCLUDE, the relay SHOULD NOT forward datagrams that originate from sources in the filter source list unless the relay architecture does not readily support source filtering. A relay MAY ignore the source list if necessary because gateways are expected to do their own source filtering.
如果排除隧道端点上的组条目的组筛选器模式，则中继不应转发源自筛选器源列表中源的数据报，除非中继体系结构不支持源筛选器。如有必要，中继可以忽略源列表，因为网关需要自己进行源过滤。
This section describes relay requirements related to the teardown message sequence described in Section 4.2.1.3.
本节描述了与第4.2.1.3节所述拆卸消息序列相关的继电器要求。
When a relay (that supports the Teardown message) receives a Teardown message, it MUST first authenticate the source of the Teardown message by verifying that the Response MAC carried by the Teardown message is equal to a MAC value computed from the fields carried by the Teardown message. The method used to compute the MAC differs from that used to generate and validate the Membership Query and Membership Update messages in that the source IP address and source UDP port number used to compute the MAC are taken from the Gateway IP
当中继（支持拆卸消息）接收到拆卸消息时，它必须首先通过验证拆卸消息携带的响应MAC等于根据拆卸消息携带的字段计算的MAC值来验证拆卸消息的源。用于计算MAC的方法不同于用于生成和验证成员资格查询和成员资格更新消息的方法，因为用于计算MAC的源IP地址和源UDP端口号取自网关IP
Address and Gateway Port Number fields in the Teardown message rather than from the IP and UDP headers in the datagram that carries the Teardown message. The MAC computation is described in Section 5.3.5. A relay MUST ignore a Teardown message if the computed MAC does not equal the value of the Response MAC field.
拆卸消息中的地址和网关端口号字段，而不是来自承载拆卸消息的数据报中的IP和UDP报头。MAC计算如第5.3.5节所述。如果计算的MAC不等于响应MAC字段的值，则中继必须忽略拆卸消息。
If a relay determines that a Teardown message is authentic, it MUST immediately stop transmitting Multicast Data messages to the endpoint identified by the Gateway IP Address and Gateway Port Number fields in the message. The relay MUST eventually delete any group membership and forwarding state associated with the endpoint but MAY delay doing so to allow a gateway to recreate group membership state on a new endpoint and thereby avoid making unnecessary (temporary) changes in upstream routing/forwarding state.
如果中继确定拆卸消息是可信的，则必须立即停止向消息中网关IP地址和网关端口号字段标识的端点发送多播数据消息。中继最终必须删除与端点相关联的任何组成员身份和转发状态，但可能会延迟这样做，以允许网关在新端点上重新创建组成员身份状态，从而避免对上游路由/转发状态进行不必要的（临时）更改。
The state changes made by a relay when processing a Teardown message MUST be identical to those that would be made if the relay had received an IGMP/MLD report that would cause the IGMP or MLD protocol to delete all existing group records in the group membership database associated with the endpoint. The processing of the Teardown message should trigger or mimic the normal interaction between IGMP or MLD and a multicast protocol to produce required changes in forwarding state and possibly send prune/leave messages towards upstream routers.
中继在处理拆卸消息时所做的状态更改必须与中继收到IGMP/MLD报告时所做的状态更改相同，该报告将导致IGMP或MLD协议删除与端点关联的组成员数据库中的所有现有组记录。拆卸消息的处理应触发或模拟IGMP或MLD与多播协议之间的正常交互，以产生转发状态的所需变化，并可能向上游路由器发送修剪/离开消息。
When a multicast IP datagram is forwarded to the relay pseudo-interface, the relay MUST, for each gateway that has expressed an interest in receiving the datagram, encapsulate the IP datagram into a Multicast Data message or messages and send that message or messages to the gateway. This process is highly implementation dependent but conceptually requires the following steps:
当多播IP数据报被转发到中继伪接口时，对于表示有兴趣接收数据报的每个网关，中继必须将IP数据报封装到多播数据消息中，并将该消息发送到网关。此过程高度依赖于实现，但在概念上需要以下步骤：
o Use the IP datagram source and destination address to look up the appropriate (*,G) or (S,G) entry in the endpoint forwarding table created for the pseudo-interface as a result of IGMP/MLD processing.
o 使用IP数据报源地址和目标地址在作为IGMP/MLD处理结果而为伪接口创建的端点转发表中查找适当的（*，G）或（S，G）条目。
o Possibly replicate the datagram for each gateway endpoint listed for that (*,G) or (S,G) entry.
o 可能会为该（*，G）或（S，G）条目列出的每个网关端点复制数据报。
o If the multicast IP datagram size exceeds the Tunnel MTU as determined according to the procedure described in Section 5.3.3.6.1, the relay must execute the procedure described in Section 5.3.3.6.2.
o 如果多播IP数据报大小超过根据第5.3.3.6.1节所述程序确定的隧道MTU，则中继必须执行第5.3.3.6.2节所述程序。
o Encapsulate and transmit the IP datagram according to the procedure described in Section 5.3.3.6.3.
o 按照第5.3.3.6.3节所述程序封装和传输IP数据报。
The relay pseudo-interface MUST ignore any other IP datagrams forwarded to the pseudo-interface.
中继伪接口必须忽略转发到伪接口的任何其他IP数据报。
A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel that originates on the relay. A relay will use the TMTU value to determine whether an incoming multicast IP datagram can be delivered downstream in a Membership Data message without fragmentation. A relay MUST compute the TMTU by subtracting the size of the Membership Data message headers (IP, UDP, and AMT) from the current Path MTU (PMTU) associated with each AMT tunnel. The relay MUST maintain a PMTU value on a per-tunnel or per-relay basis. A relay MUST support one or both of the following methods for determining the PMTU value:
继电器必须为源自继电器的每个AMT通道计算通道MTU（TMTU）值。中继将使用TMTU值来确定传入的多播IP数据报是否可以在成员数据消息中向下游传递，而不会出现碎片。中继必须通过从与每个AMT隧道关联的当前路径MTU（PMTU）中减去成员数据消息头（IP、UDP和AMT）的大小来计算TMTU。继电器必须在每个通道或每个继电器的基础上保持PMTU值。继电器必须支持以下一种或两种方法来确定PMTU值：
o The relay MAY provide a configuration option that establishes a fixed PMTU that will be applied to all AMT tunnels originating at the relay.
o 继电器可提供一个配置选项，用于建立一个固定的PMTU，该PMTU将应用于源自继电器的所有AMT隧道。
o The relay MAY dynamically adjust PMTU value(s) in response to receipt of ICMP/ICMPv6 Datagram Too Big messages as described in [RFC1191] and [RFC1981].
o 如[RFC1191]和[RFC1981]中所述，中继器可响应ICMP/ICMPv6数据报过大消息的接收动态调整PMTU值。
If a relay supports dynamic adjustment of per-tunnel or per-relay PMTU values in response to ICMP messages, the relay MUST provide a configuration option that disables this feature and also provide a configuration option that establishes a minimum PMTU for all tunnels. These configuration options may be used to mitigate certain types of denial-of-service attacks (see Section 6). When dynamic PMTU adjustments are disabled, the PMTU for all tunnels MUST default to the Link MTU (first hop) on the downstream interface.
如果继电器支持响应ICMP消息动态调整每个通道或每个继电器的PMTU值，则继电器必须提供禁用此功能的配置选项，并提供为所有通道建立最小PMTU的配置选项。这些配置选项可用于缓解某些类型的拒绝服务攻击（请参阅第6节）。当禁用动态PMTU调整时，所有隧道的PMTU必须默认为下游接口上的链路MTU（第一跳）。
This section defines procedures that a relay must execute when it receives a multicast datagram whose size is greater than the Tunnel MTU of the tunnel or tunnels through which it must be delivered.
本节定义了中继在接收多播数据报时必须执行的过程，该多播数据报的大小大于必须通过的一个或多个隧道的隧道MTU。
If the DF bit in the multicast datagram header is set to 1 (Don't Fragment), the relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv4 [RFC0792] Destination Unreachable message to the source, with code 4 (fragmentation needed and DF set). The ICMP Destination Unreachable message MUST contain a Next-Hop MTU (as specified by [RFC1191]), and the relay MUST set the Next-Hop MTU to the TMTU associated with the tunnel or tunnels. If the DF bit in the multicast datagram header is set to 0 (May Fragment), the relay MUST fragment the datagram and encapsulate each fragment within Multicast Data messages for transmission through the tunnel or tunnels. This ensures that gateways will receive complete, non-fragmented Multicast Data messages, containing fragmented multicast datagram payloads. The relay SHOULD avoid generating a separate ICMP message for each tunnel but instead send a single ICMP message with a Next-Hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded.
如果多播数据报报头中的DF位设置为1（不分段），中继必须丢弃该数据包，如果数据报来自SSM源，则向源发送ICMPv4[RFC0792]目的地不可到达消息，代码为4（需要分段并设置DF）。ICMP目的地不可到达消息必须包含下一跳MTU（由[RFC1191]指定），并且中继必须将下一跳MTU设置为与一个或多个隧道关联的TMTU。如果多播数据报报头中的DF位设置为0（可能是片段），则中继必须对数据报进行片段化，并将每个片段封装在多播数据消息中，以便通过一个或多个隧道进行传输。这确保网关将接收完整、非分段的多播数据消息，其中包含分段的多播数据报有效负载。中继应避免为每个隧道生成单独的ICMP消息，而是发送单个ICMP消息，下一跳MTU等于数据报要转发到的所有隧道中最小的TMTU。
The relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message to the payload source. The MTU specified in the Packet Too Big message MUST be equal to the TMTU associated with the tunnel or tunnels. The relay SHOULD avoid generating a separate ICMPv6 message for each tunnel but instead send a single ICMPv6 message with a Next-Hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded.
中继器必须丢弃数据包，如果数据报来自SSM源，则向有效负载源发送ICMPv6[RFC4443]数据包过大消息。数据包过大消息中指定的MTU必须等于与隧道关联的TMTU。中继应避免为每个隧道生成单独的ICMPv6消息，而是发送单个ICMPv6消息，下一跳MTU等于数据报要转发到的所有隧道中最小的TMTU。
A relay encapsulates a multicast IP datagram in a UDP/IP Membership Data message, using the tunnel endpoint UDP/IP address as the destination address and the unicast Relay Address and port number as the source UDP/IP address. To ensure successful NAT traversal, the source address and port MUST match the destination address and port carried by the Membership Update message sent by the gateway to create the forwarding table entry.
中继将多播IP数据报封装在UDP/IP成员数据消息中，使用隧道端点UDP/IP地址作为目标地址，单播中继地址和端口号作为源UDP/IP地址。为了确保NAT穿越成功，源地址和端口必须与网关发送的成员身份更新消息所携带的目标地址和端口相匹配，以创建转发表条目。
If possible, the relay SHOULD compute a valid, non-zero checksum for the UDP datagram carrying the Multicast Data message. See Section 4.2.2.3.
如果可能，中继应该为承载多播数据消息的UDP数据报计算有效的非零校验和。见第4.2.2.3节。
The following sections describe additional requirements related to the IP protocol of the tunnel and that of the multicast IP datagram.
以下各节描述了与隧道IP协议和多播IP数据报IP协议相关的附加要求。
When a relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in the payload header is set to 1 (Don't Fragment), the relay MUST set the DF bit in the Multicast Data IP header to 1. When a relay delivers an IPv4 payload over an IPv4 tunnel and the DF bit in the payload header is set to 0 (May Fragment), by default, the relay MUST set the DF bit in the Multicast Data IP header to 1. However, a relay MAY provide a configuration option that allows the DF bit to be copied from the payload header to the Multicast Data IP header to allow downstream fragmentation of the Multicast Data message. When a relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST set the DF bit in the Multicast Data IP header to 1. The relay MUST NOT transmit a Multicast Data message with an IP header in which the MF (More Fragments) bit is set to 1.
当中继通过IPv4隧道传递IPv4有效负载且有效负载标头中的DF位设置为1（不分段）时，中继必须将多播数据IP标头中的DF位设置为1。当中继通过IPv4隧道传递IPv4有效负载，并且有效负载报头中的DF位设置为0（可能是碎片）时，默认情况下，中继必须将多播数据IP报头中的DF位设置为1。然而，中继器可以提供配置选项，该配置选项允许将DF比特从有效负载报头复制到多播数据IP报头，以允许多播数据消息的下游分段。当中继通过IPv4隧道传递IPv6有效负载时，中继必须将多播数据IP报头中的DF位设置为1。中继不得传输IP报头中MF（更多片段）位设置为1的多播数据消息。
When tunneling over IPv6, a relay MUST NOT emit a Multicast Data message datagram containing an IPv6 fragment header.
通过IPv6进行隧道传输时，中继不得发出包含IPv6片段头的多播数据消息数据报。
If a relay receives a sequence of ICMP or ICMPv6 Destination Unreachable messages (excluding ICMP code 4; see below) in response to transmission of a sequence of AMT Multicast Data messages to a gateway, the relay SHOULD discontinue sending messages to that gateway and shut down the tunnel for that gateway.
如果中继接收到一系列ICMP或ICMPv6目的地不可到达消息（不包括ICMP代码4；见下文），以响应向网关传输AMT多播数据消息的序列，则中继应停止向该网关发送消息，并关闭该网关的隧道。
Handling of ICMP Destination Unreachable messages with code 4, "fragmentation needed and DF set" (i.e., "Datagram Too Big") is covered in Section 5.3.3.6.1. If a relay provides this capability, it MUST provide a configuration option that indicates what number of sequential Destination Unreachable messages can be received and ignored before the relay will automatically shut down a tunnel.
第5.3.3.6.1节介绍了代码为4“需要碎片和DF设置”（即“数据报太大”）的ICMP目标无法到达消息的处理。如果中继器提供此功能，则它必须提供一个配置选项，该选项指示在中继器自动关闭隧道之前，可以接收和忽略多少个连续的目标不可访问消息。
A relay MUST maintain a timer or timers whose expiration will trigger the removal of any group subscriptions and forwarding state previously created for a gateway endpoint should the gateway fail to refresh the group membership state within a specified time interval.
中继必须维护一个或多个计时器，如果网关未能在指定的时间间隔内刷新组成员身份状态，则其过期将触发删除以前为网关端点创建的任何组订阅和转发状态。
A relay MAY use a variant of the IGMPv3/MLDv2 state management protocol described in Section 6 of [RFC3376] or Section 7 of [RFC3810] or may maintain a per-endpoint timer to trigger the deletion of group membership state.
中继器可以使用[RFC3376]第6节或[RFC3810]第7节中描述的IGMPv3/MLDv2状态管理协议的变体，或者可以维护每端点定时器来触发组成员状态的删除。
If a per-endpoint timer is used, the relay MUST restart this timer each time it receives a new Membership Update message from the gateway endpoint.
如果使用每端点计时器，则中继必须在每次从网关端点接收到新的成员身份更新消息时重新启动此计时器。
The endpoint timer duration MAY be computed from tunable IGMP/MLD variables as follows:
端点计时器持续时间可根据可调IGMP/MLD变量计算，如下所示：
((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval
((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval
If IGMP/MLD default values are used for these variables, the gateway will time out after 125s * 2 + 10s = 260s. The timer duration MUST be greater than the query interval suggested in the last Membership Query message sent to the gateway endpoint.
如果这些变量使用IGMP/MLD默认值，网关将在125s*2+10s=260s后超时。计时器持续时间必须大于发送到网关终结点的上次成员资格查询消息中建议的查询间隔。
Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the Query_Response_Interval value SHOULD be greater than or equal to 10s to allow for packet loss and round-trip time in the Request/ Membership Query message exchange.
无论使用何种定时器（IGMPv3/MLDv2或端点），查询响应间隔值应大于或等于10s，以允许请求/成员查询消息交换中的数据包丢失和往返时间。
A relay may be configured with various service limits to ensure a minimum level of performance for gateways that connect to it.
继电器可以配置各种服务限制，以确保连接到它的网关的最低性能水平。
If a relay has determined that it has reached or exceeded maximum allowable capacity or has otherwise exhausted resources required to support additional gateways, it SHOULD withdraw any Relay Discovery Address Prefix it has advertised into the unicast internetwork and SHOULD set the L flag in any Membership Query messages it returns to gateways while in this state.
如果中继已确定其已达到或超过最大允许容量，或已耗尽支持其他网关所需的资源，它应该收回它在单播互联网络中播发的任何中继发现地址前缀，并且应该在处于该状态时返回到网关的任何成员资格查询消息中设置L标志。
If the relay receives an update from a gateway that adds group membership or forwarding state for an endpoint that has already reached maximum allowable state entries, the relay SHOULD continue to accept updates from the gateway but ignore any group membership/ forwarding state additions requested by that gateway.
如果中继接收到来自网关的更新，该网关为已达到最大允许状态项的端点添加组成员资格或转发状态，则中继应继续接受来自网关的更新，但忽略该网关请求的任何组成员资格/转发状态添加。
If the relay receives an update from a gateway that would create a new tunnel endpoint for a source IP address that has already reached the maximum allowable number of endpoints (maximum UDP ports), it should simply ignore the Membership Update.
如果中继接收到来自网关的更新，该更新将为已达到允许的最大端点数（最大UDP端口数）的源IP地址创建新的隧道端点，则它应该忽略成员身份更新。
The following steps should be treated as an abstract description of the shutdown procedure for a relay:
以下步骤应视为继电器停机程序的抽象描述：
o Withdraw the Relay Discovery Address Prefix advertisement (if used).
o 撤回中继发现地址前缀播发（如果使用）。
o Stop listening for Relay Discovery messages.
o 停止侦听中继发现消息。
o Stop listening for control messages from gateways.
o 停止侦听来自网关的控制消息。
o Stop sending data messages to gateways.
o 停止向网关发送数据消息。
o Delete all AMT group membership and forwarding state created on the relay, coordinating with the multicast routing protocol to update the group membership state on upstream interfaces as required.
o 删除在中继上创建的所有AMT组成员身份和转发状态，与多播路由协议协调，根据需要更新上游接口上的组成员身份状态。
A Response MAC value is computed by the relay. A Response MAC computation is required in the following situations:
响应MAC值由继电器计算。在以下情况下需要响应MAC计算：
o To generate a Response MAC value from a Request message for inclusion in a Membership Query message.
o 从请求消息生成响应MAC值以包含在成员资格查询消息中。
o To generate a Response MAC value from a Membership Update message for use in authenticating the Response MAC carried within that message.
o 从成员身份更新消息生成响应MAC值，用于验证该消息中携带的响应MAC。
o To generate a Response MAC value from a Teardown message to authenticate the Response MAC carried within that message.
o 从拆卸消息生成响应MAC值，以验证该消息中携带的响应MAC。
Gateways treat the Response MAC field as an opaque value, so a relay implementation may generate the MAC using any method available to it. The RECOMMENDED method for computing the Response MAC is to compute a cryptographically secure hash or keyed-hash digest from the following values:
网关将响应MAC字段视为不透明值，因此中继实现可以使用任何可用方法生成MAC。计算响应MAC的推荐方法是从以下值计算加密安全哈希或密钥哈希摘要：
o The source IP address of the message (or Teardown Gateway IP Address field).
o 消息的源IP地址（或拆卸网关IP地址字段）。
o The source UDP port of the message (or Teardown Gateway Port Number field).
o 消息的源UDP端口（或拆卸网关端口号字段）。
o The Request Nonce contained in the message.
o 消息中包含的请求Nonce。
o A private secret or key known only to the relay.
o 只有中继器知道的私人秘密或密钥。
If the relay implementation uses a private secret (or key) to compute the Response MAC value, the relay SHOULD periodically compute a new private secret. The RECOMMENDED maximum interval is 2 hours. A relay MUST retain the prior secret for use in verifying MAC values that were sent to gateways just prior to the use of the new secret.
如果中继实现使用私有密钥（或密钥）计算响应MAC值，则中继应定期计算新的私有密钥。建议的最大间隔为2小时。中继必须保留先前的机密，以便在使用新机密之前验证发送到网关的MAC值。
AMT is not intended to be a strongly secure protocol. In general, the protocol provides the same level of security and robustness as is provided by the UDP, IGMP, and MLD protocols on which it relies. The lack of strong security features can be largely attributed to the desire to make the protocol lightweight by minimizing the state and computation required to service a single gateway, thereby allowing a relay to service a larger number of gateways.
AMT不是一个强安全协议。一般来说，该协议提供与它所依赖的UDP、IGMP和MLD协议相同级别的安全性和健壮性。缺乏强大的安全功能在很大程度上可归因于希望通过最小化为单个网关提供服务所需的状态和计算来使协议轻量级，从而允许中继为更多网关提供服务。
Many of the threats and vectors described in [RFC3552] may be employed against the protocol to launch various types of denial-of-service attacks that can affect the functioning of gateways or their ability to locate and communicate with a relay. These scenarios are described below.
[RFC3552]中描述的许多威胁和向量可用于攻击协议，以发起各种类型的拒绝服务攻击，这些攻击可影响网关的功能或其定位和与中继通信的能力。这些场景描述如下。
As is the case for UDP, IGMP, and MLD, the AMT protocol provides no mechanisms for ensuring message delivery or integrity. The protocol does not provide confidentiality -- multicast groups, sources, and streams requested by a gateway are sent in the clear.
与UDP、IGMP和MLD一样，AMT协议没有提供任何机制来确保消息传递或完整性。该协议不提供机密性——网关请求的多播组、源和流以明文形式发送。
The protocol does use a three-way handshake to provide trivial source authentication for state allocation and updates (see below). The protocol also requires gateways and relays to ignore malformed messages and those messages that do not carry expected address values, protocol payload types, or content.
该协议确实使用三方握手来为状态分配和更新提供简单的源身份验证（见下文）。该协议还要求网关和中继器忽略格式错误的消息以及那些不携带预期地址值、协议有效负载类型或内容的消息。
The three-way handshake provided by the membership update message sequence (see Section 4.2.1.2) provides a defense against source-spoofing-based resource-exhaustion attacks on a relay by requiring source authentication before state allocation. However, in an effort
成员身份更新消息序列（参见第4.2.1.2节）提供的三方握手通过在状态分配之前要求源身份验证，为防止中继上基于源欺骗的资源耗尽攻击提供了一种防御。但是,
to consume computational resources, attackers may still attempt to flood a relay with Request and Membership Update messages to force the relay to make the MAC authentication computations. Implementations may choose to limit the frequency with which a relay responds to Request messages sent from a single IP address or IP address and UDP port pair, but support for this functionality is not required. The three-way handshake provides no defense against an eavesdropping or man-in-the-middle attacker.
为了消耗计算资源，攻击者仍可能试图向中继发送请求和成员身份更新消息，以迫使中继进行MAC身份验证计算。实现可以选择限制中继响应从单个IP地址或IP地址和UDP端口对发送的请求消息的频率，但不需要支持此功能。三方握手无法防御窃听者或中间人攻击者。
Attackers that execute the gateway protocol may consume relay resources by instantiating a large number of tunnels or joining a large number of multicast streams. A relay implementation should provide a mechanism for limiting the number of tunnels (Multicast Data message destinations) that can be created for a single gateway source address. Relays should also provide a means for limiting the number of joins per tunnel instance as a defense against these attacks.
执行网关协议的攻击者可能通过实例化大量隧道或加入大量多播流来消耗中继资源。中继实现应提供一种机制，用于限制可为单个网关源地址创建的隧道（多播数据消息目的地）的数量。中继还应提供一种方法来限制每个隧道实例的连接数，以防御这些攻击。
Relays may withdraw their AMT anycast prefix advertisement when they reach configured maximum capacity or exhaust required resources. This behavior allows gateways to use the relay discovery process to find the next topologically nearest relay that has advertised the prefix. This behavior also allows a successful resource-exhaustion attack to propagate from one relay to the next until all relays reachable using the anycast address have effectively been taken offline. This behavior may also be used to acquire the unicast addresses for individual relays that can then be used to launch a DDoS attack on all of the relays without using the relay discovery process. To prevent wider disruption of AMT-based distribution networks, relay anycast address advertisements can be limited to specific administrative routing domains. This will isolate such attacks to a single domain.
当继电器达到配置的最大容量或耗尽所需资源时，可以撤回其AMT选播前缀播发。此行为允许网关使用中继发现过程查找已播发前缀的下一个拓扑上最近的中继。此行为还允许成功的资源耗尽攻击从一个中继传播到下一个中继，直到所有可使用选播地址访问的中继有效脱机。此行为还可用于获取单个中继的单播地址，然后可用于在不使用中继发现过程的情况下对所有中继发起DDoS攻击。为了防止基于AMT的分销网络发生更广泛的中断，中继选播地址广告可以限制在特定的管理路由域。这将把此类攻击隔离到单个域。
The Path and Tunnel MTU adjustment (discovery) procedure described in Section 5.3.3.6.1 is vulnerable to two denial-of-service attacks (see Section 8 of [RFC1191] for details). Both attacks are based on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small Path MTU. In the second attack, the forged message indicates an inordinately large Path MTU. In both cases, throughput is adversely affected. In order to mitigate such attacks, relay implementations MUST include a configuration option to disable Path MTU adjustments on AMT tunnels.
第5.3.3.6.1节中描述的路径和隧道MTU调整（发现）程序容易受到两次拒绝服务攻击（详情请参见[RFC1191]第8节）。这两种攻击都是基于恶意方向主机发送伪造的ICMPv4目的地不可访问或ICMPv6数据包过大消息。在第一次攻击中，伪造消息表示路径MTU过小。在第二次攻击中，伪造消息表示MTU路径过大。在这两种情况下，吞吐量都会受到不利影响。为了减轻此类攻击，中继实现必须包括一个配置选项，以禁用AMT隧道上的路径MTU调整。
A passive eavesdropper may launch a denial-of-service attack on a gateway by capturing a Membership Query or Membership Update message and using the Request Nonce and message authentication code carried by the captured message to send a spoofed Membership Update or Teardown message to the relay. The spoofed messages may be used to modify or destroy group membership state associated with the gateway, thereby changing or interrupting the multicast traffic flows.
被动窃听者可通过捕获成员资格查询或成员资格更新消息并使用捕获的消息所携带的请求Nonce和消息认证码向中继发送伪造的成员资格更新或拆卸消息，在网关上发起拒绝服务攻击。欺骗消息可用于修改或破坏与网关相关联的组成员状态，从而改变或中断多播业务流。
A passive eavesdropper may also spoof Multicast Data messages in an attempt to overload the gateway or to disrupt or supplant existing traffic flows. A properly implemented gateway will filter Multicast Data messages that do not originate from the expected Relay Address and should filter non-multicast packets and multicast IP packets whose group or source addresses are not included in the current reception state for the gateway pseudo-interface.
被动窃听者还可能欺骗多播数据消息，试图使网关过载或中断或取代现有的通信流。正确实现的网关将过滤并非源自预期中继地址的多播数据消息，并应过滤组或源地址未包含在网关伪接口当前接收状态中的非多播数据包和多播IP数据包。
An active eavesdropper may launch a man-in-the-middle attack in which messages normally exchanged between a gateway and relay are intercepted, modified, spoofed, or discarded by the attacker. The attacker may deny access to, modify, or replace requested multicast traffic. The AMT protocol provides no means for detecting or defending against a man-in-the-middle attack -- any such functionality must be provided by multicast receiver applications through independent detection and validation of incoming multicast datagrams.
主动窃听者可能发起中间人攻击，攻击者拦截、修改、欺骗或丢弃通常在网关和中继之间交换的消息。攻击者可能会拒绝访问、修改或替换请求的多播流量。AMT协议没有提供检测或防御中间人攻击的手段——任何此类功能都必须由多播接收器应用程序通过独立检测和验证传入的多播数据报来提供。
The anycast discovery technique for finding relays (see Section 4.1.4) introduces a risk that a rogue router or a rogue Autonomous System (AS) could introduce a bogus route to a specific Relay Discovery Address Prefix and thus divert or absorb Relay Discovery messages sent by gateways. Network managers must guarantee the integrity of their routing to a particular Relay Discovery Address Prefix in much the same way that they guarantee the integrity of all other routes.
用于查找中继的选播发现技术（见第4.1.4节）带来了一种风险，即恶意路由器或恶意自治系统（AS）可能会向特定中继发现地址前缀引入虚假路由，从而转移或吸收网关发送的中继发现消息。网络管理器必须保证其到特定中继发现地址前缀的路由的完整性，其方式与保证所有其他路由的完整性大致相同。
An attacker forging or modifying a Membership Query or Membership Update message may attempt to embed something other than an IGMP or MLD message within the encapsulated IP packet carried by these messages in an effort to introduce these into the recipient's IP stack. A properly implemented gateway or relay will ignore any such messages and may further choose to ignore Membership Query messages that do not contain IGMP/MLD General Query or Membership Update messages that do not contain IGMP/MLD membership reports.
伪造或修改成员资格查询或成员资格更新消息的攻击者可能试图在这些消息所携带的封装IP数据包中嵌入IGMP或MLD消息以外的内容，以将其引入收件人的IP堆栈。正确实现的网关或中继将忽略任何此类消息，并可进一步选择忽略不包含IGMP/MLD常规查询的成员资格查询消息或不包含IGMP/MLD成员资格报告的成员资格更新消息。
Properly implemented gateways and relays will also filter encapsulated IP packets that appear corrupted or truncated by verifying packet length and checksums.
正确实现的网关和中继还将通过验证数据包长度和校验和来过滤出现损坏或截断的封装IP数据包。
The following unicast prefixes have been assigned to provide anycast routing of Relay Discovery messages to public AMT relays as described in Section 4.1.4. Address assignments within these prefixes are described in Section 4.1.5.2.
如第4.1.4节所述，已分配以下单播前缀，以向公共AMT中继提供中继发现消息的选播路由。第4.1.5.2节描述了这些前缀中的地址分配。
IANA has assigned 192.52.193.0/24 from the "IANA IPv4 Special-Purpose Address Registry". The block has been registered as follows:
IANA已从“IANA IPv4专用地址注册表”分配192.52.193.0/24。该区块已登记如下：
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block |192.52.193.0/24 |
| Name | AMT |
| RFC | [RFC7450] |
| Allocation Date | 2014-12 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block |192.52.193.0/24 |
| Name | AMT |
| RFC | [RFC7450] |
| Allocation Date | 2014-12 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+
IANA has registered the following special-purpose address block for IPv6 anycast AMT relay discovery.
IANA已为IPv6选播AMT中继发现注册了以下专用地址块。
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 2001:3::/32 |
| Name | AMT |
| RFC | [RFC7450] |
| Allocation Date | 2014-12 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 2001:3::/32 |
| Name | AMT |
| RFC | [RFC7450] |
| Allocation Date | 2014-12 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+
The UDP port number 2268 has been reserved with IANA for use in the implementation and deployment of AMT. The protocol described by this document continues to use this port number according to the intent of the original request. IANA has updated the assignee, contact, and reference fields for this port number in accordance with this document.
IANA保留了UDP端口号2268，用于AMT的实施和部署。本文档描述的协议根据原始请求的意图继续使用此端口号。IANA已根据本文件更新了该端口号的受让人、联系人和参考字段。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月<http://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810]Vida，R.，Ed.，和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 38102004年6月<http://www.rfc-editor.org/info/rfc3810>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月<http://www.rfc-editor.org/info/rfc4607>.
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月<http://www.rfc-editor.org/info/rfc4787>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981, <http://www.rfc-editor.org/info/rfc0791>.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月<http://www.rfc-editor.org/info/rfc0791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981, <http://www.rfc-editor.org/info/rfc0792>.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月<http://www.rfc-editor.org/info/rfc0792>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月<http://www.rfc-editor.org/info/rfc1112>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月<http://www.rfc-editor.org/info/rfc1191>.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993, <http://www.rfc-editor.org/info/rfc1546>.
[RFC1546]帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC15461993年11月<http://www.rfc-editor.org/info/rfc1546>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月<http://www.rfc-editor.org/info/rfc1981>.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997, <http://www.rfc-editor.org/info/rfc2236>.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月<http://www.rfc-editor.org/info/rfc2236>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月<http://www.rfc-editor.org/info/rfc2663>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月<http://www.rfc-editor.org/info/rfc2710>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月<http://www.rfc-editor.org/info/rfc3552>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月<http://www.rfc-editor.org/info/rfc4443>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月<http://www.rfc-editor.org/info/rfc4601>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，2006年12月<http://www.rfc-editor.org/info/rfc4786>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013, <http://www.rfc-editor.org/info/rfc6935>.
[RFC6935]Eubanks，M.，Chimento，P.和M.Westerlund，“隧道数据包的IPv6和UDP校验和”，RFC 69352013年4月<http://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.
[RFC6936]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，RFC 69362013年4月<http://www.rfc-editor.org/info/rfc6936>.
Acknowledgments
致谢
The author would like to thank the following individuals for their suggestions, comments, and corrections:
作者感谢以下个人的建议、评论和更正：
Mark Altom Toerless Eckert Marshall Eubanks Gorry Fairhurst Dino Farinacci Lenny Giuliano Andy Huang Tom Imburgia Patricia McCrink Han Nguyen Doug Nortz Pekka Savola Robert Sayko Greg Shepherd Steve Simlo Mohit Talwar Lorenzo Vicisano Kurt Windisch John Zwiebel
马克·阿尔托姆·艾克特·马歇尔·尤班克斯·戈里·费尔赫斯特·迪诺·法里纳奇·莱尼·朱利亚诺·安迪·汤姆·伊姆伯吉亚·帕特里夏·麦克林克·汉·阮·道格·诺兹·佩卡·萨沃拉·罗伯特·赛科·格雷格·谢泼德·斯蒂夫·西姆洛·莫希特·塔瓦尔·洛伦佐·维西萨诺·库尔特·温迪奇·约翰·兹维贝尔
The anycast discovery mechanism described in this document is based on similar work done by the NGTrans WG for obtaining automatic IPv6 connectivity without explicit tunnels ("6to4"). Tony Ballardie provided helpful discussion that inspired this document.
本文档中描述的选播发现机制基于NGTrans WG为获得无显式隧道的自动IPv6连接（“6to4”）所做的类似工作。托尼·巴拉迪（Tony Ballardi）提供了启发本文件的有益讨论。
Juniper Networks was instrumental in funding several versions of this document as well as an open source implementation.
Juniper Networks为本文档的几个版本以及开源实现提供了资金。
Contributors
贡献者
The following people provided significant contributions to the design of the protocol and earlier versions of this specification:
以下人员对协议和本规范早期版本的设计做出了重大贡献：
Amit Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 United States EMail: amitag@microsoft.com
Amit Aggarwal Microsoft Corporation One Microsoft Way Redmond，WA 98052-6399美国电子邮件：amitag@microsoft.com
Thomas Morin Orange 2, avenue Pierre Marzin Lannion 22300 France EMail: thomas.morin@orange.com
托马斯·莫林·奥兰治2号大街皮埃尔·马津·兰尼翁22300法国电子邮件：托马斯。morin@orange.com
Dirk Ooms OneSparrow Robert Molsstraat 11; 2018 Antwerp Belgium EMail: dirk@onesparrow.com
德克是一只麻雀，罗伯特·莫斯特拉特，11岁；2018安特卫普比利时电子邮件：dirk@onesparrow.com
Tom Pusateri !j Wake Forest, NC United States EMail: pusateri@bangj.com
汤姆·普萨特里！j Wake Forest，北卡罗来纳州美国电子邮件：pusateri@bangj.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 United States EMail: dthaler@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond，WA 98052-6399美国电子邮件：dthaler@microsoft.com
Author's Address
作者地址
Gregory Bumgardner
格雷戈里·邦加德纳
Phone: +1 541 343 6790
EMail: gbumgard@gmail.com
Phone: +1 541 343 6790
EMail: gbumgard@gmail.com