Network Working Group M. Handley
Request for Comments: 2776 ACIRI
Category: Standards Track D. Thaler
Microsoft
R. Kermode
Motorola
February 2000
Network Working Group M. Handley
Request for Comments: 2776 ACIRI
Category: Standards Track D. Thaler
Microsoft
R. Kermode
Motorola
February 2000
Multicast-Scope Zone Announcement Protocol (MZAP)
多播作用域区域公告协议（MZAP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby common misconfigurations of administrative scope zones can be discovered.
本文档定义了一个协议，即多播作用域公告协议（MZAP），用于发现与特定位置相关的多播管理作用域。MZAP还提供了发现管理范围区域常见错误配置的机制。
Table of Contents
目录
1 Introduction ................................................ 2
2 Terminology ................................................. 4
3 Overview .................................................... 5
3.1 Scope Nesting ............................................. 6
3.2 Other Messages ............................................ 7
3.3 Zone IDs .................................................. 7
4 Detecting Router Misconfigurations .......................... 8
4.1 Detecting non-convex scope zones .......................... 8
4.2 Detecting leaky boundaries for non-local scopes ........... 9
4.3 Detecting a leaky Local Scope zone ........................ 10
4.4 Detecting conflicting scope zones ......................... 10
5 Packet Formats .............................................. 11
5.1 Zone Announcement Message ................................. 14
5.2 Zone Limit Exceeded (ZLE) ................................. 15
5.3 Zone Convexity Message .................................... 15
1 Introduction ................................................ 2
2 Terminology ................................................. 4
3 Overview .................................................... 5
3.1 Scope Nesting ............................................. 6
3.2 Other Messages ............................................ 7
3.3 Zone IDs .................................................. 7
4 Detecting Router Misconfigurations .......................... 8
4.1 Detecting non-convex scope zones .......................... 8
4.2 Detecting leaky boundaries for non-local scopes ........... 9
4.3 Detecting a leaky Local Scope zone ........................ 10
4.4 Detecting conflicting scope zones ......................... 10
5 Packet Formats .............................................. 11
5.1 Zone Announcement Message ................................. 14
5.2 Zone Limit Exceeded (ZLE) ................................. 15
5.3 Zone Convexity Message .................................... 15
5.4 Not-Inside Message ........................................ 16
6 Message Processing Rules .................................... 17
6.1 Internal entities listening to MZAP messages .............. 17
6.2 Sending ZAMs .............................................. 18
6.3 Receiving ZAMs ............................................ 18
6.4 Sending ZLEs .............................................. 20
6.5 Receiving ZLEs ............................................ 20
6.6 Sending ZCMs .............................................. 21
6.7 Receiving ZCMs ............................................ 21
6.8 Sending NIMs .............................................. 21
6.9 Receiving NIMs ............................................ 22
7 Constants ................................................... 22
8 Security Considerations ..................................... 23
9 Acknowledgements ............................................ 24
10 References ................................................. 25
11 Authors' Addresses ......................................... 26
12 Full Copyright Statement ................................... 27
5.4 Not-Inside Message ........................................ 16
6 Message Processing Rules .................................... 17
6.1 Internal entities listening to MZAP messages .............. 17
6.2 Sending ZAMs .............................................. 18
6.3 Receiving ZAMs ............................................ 18
6.4 Sending ZLEs .............................................. 20
6.5 Receiving ZLEs ............................................ 20
6.6 Sending ZCMs .............................................. 21
6.7 Receiving ZCMs ............................................ 21
6.8 Sending NIMs .............................................. 21
6.9 Receiving NIMs ............................................ 22
7 Constants ................................................... 22
8 Security Considerations ..................................... 23
9 Acknowledgements ............................................ 24
10 References ................................................. 25
11 Authors' Addresses ......................................... 26
12 Full Copyright Statement ................................... 27
The use of administratively-scoped IP multicast, as defined in RFC 2365 [1], allows packets to be addressed to a specific range of multicast addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4) such that the packets will not cross configured administrative boundaries, and also allows such addresses to be locally assigned and hence are not required to be unique across administrative boundaries. This property of logical naming both allows for address reuse, as well as provides the capability for infrastructure services such as address allocation, session advertisement, and service location to use well-known addresses which are guaranteed to have local significance within every organization.
使用RFC 2365[1]中定义的管理范围的IP多播，允许将数据包寻址到特定范围的多播地址（例如，对于IPv4为239.0.0.0至239.255.255.255），这样数据包就不会跨越配置的管理边界，并且还允许在本地分配此类地址，因此不要求跨行政边界具有唯一性。这种逻辑命名属性既允许地址重用，也为基础设施服务（如地址分配、会话播发和服务位置）提供了使用已知地址的能力，这些已知地址保证在每个组织中都具有本地意义。
The range of administratively-scoped addresses can be subdivided by administrators so that multiple levels of administrative boundaries can be simultaneously supported. As a result, a "multicast scope" is defined as a particular range of addresses which has been given some topological meaning.
管理员可以细分管理范围的地址范围，以便同时支持多个级别的管理边界。因此，“多播范围”被定义为一个特定的地址范围，该地址范围具有一定的拓扑意义。
To support such usage, a router at an administrative boundary is configured with one or more per-interface filters, or "multicast scope boundaries". Having such a boundary on an interface means that it will not forward packets matching a configured range of multicast addresses in either direction on the interface.
为了支持这种使用，在管理边界处的路由器配置有一个或多个每个接口过滤器，或“多播作用域边界”。在接口上有这样一个边界意味着它不会在接口的任意方向上转发与配置的多播地址范围相匹配的数据包。
A specific area of the network topology which is within a boundary for a given scope is known as a "multicast scope zone". Since the same ranges can be reused within disjoint areas of the network, there may be many "multicast scope zones" for any given multicast scope. A
在给定范围的边界内的网络拓扑的特定区域称为“多播范围区域”。由于相同的范围可以在网络的不相交区域内重用，因此对于任何给定的多播作用域，可能存在许多“多播作用域区域”。A.
scope zone may have zero or more textual names (in different languages) for the scope, for human convenience. For example, if the range 239.192/14 were assigned to span an entire corporate network, it might be given (internally) the name "BigCo Private Scope".
为了方便人们，作用域区域可以有零个或多个作用域的文本名称（使用不同的语言）。例如，如果将范围239.192/14分配给整个公司网络，则可能（在内部）将其命名为“BigCo私有范围”。
Administrative scope zones may be of any size, and a particular host may be within many administrative scope zones (for different scopes, i.e., for non-overlapping ranges of addresses) of various sizes, as long as scope zones that intersect topologically do not intersect in address range.
管理范围区域可以是任何大小，并且特定主机可以位于许多不同大小的管理范围区域（对于不同的范围，即对于不重叠的地址范围）内，只要拓扑相交的范围区域在地址范围内不相交。
Applications and services are interested in various aspects of the scopes within which they reside:
应用程序和服务对其所在范围的各个方面感兴趣：
o Applications which present users with a choice of which scope in which to operate (e.g., when creating a new session, whether it is to be confined to a corporate intranet, or whether it should go out over the public Internet) are interested in the textual names which have significance to users.
o 向用户提供操作范围选择的应用程序（例如，创建新会话时，会话是否限于公司内部网，或是否应通过公共互联网进行）对用户有意义的文本名称感兴趣。
o Services which use "relative" multicast addresses (as defined in [1]) in every scope are interested in the range of addresses used by each scope, so that they can apply a constant offset and compute which address to use in each scope.
o 在每个作用域中使用“相对”多播地址（定义见[1]）的服务对每个作用域使用的地址范围感兴趣，因此它们可以应用恒定偏移量并计算在每个作用域中使用的地址。
o Address allocators are interested in the address range, and whether they are allowed to allocate addresses within the entire range or not.
o 地址分配器感兴趣的是地址范围，以及是否允许它们在整个范围内分配地址。
o Some applications and services may also be interested in the nesting relationships among scopes. For example, knowledge of the nesting relationships can be used to perform "expanding-scope" searches in a similar, but better behaved, manner to the well-known expanding ring search where the TTL of a query is steadily increased until a replier can be found. Studies have also shown that nested scopes can be useful in localizing multicast repair traffic [8].
o 一些应用程序和服务可能还对作用域之间的嵌套关系感兴趣。例如，嵌套关系的知识可用于执行“扩展范围”搜索，其方式与众所周知的扩展环搜索类似，但性能更好，其中查询的TTL稳步增加，直到找到应答器。研究还表明，嵌套作用域在定位多播修复流量方面非常有用[8]。
Two barriers currently make administrative scoping difficult to deploy and use:
目前有两个障碍使得管理范围难以部署和使用：
o Applications have no way to dynamically discover information on scopes that are relevant to them. This makes it difficult to use administrative scope zones, and hence reduces the incentive to deploy them.
o 应用程序无法动态发现与其相关的作用域上的信息。这使得使用管理范围区域变得困难，因此降低了部署它们的动机。
o Misconfiguration is easy. It is difficult to detect scope zones that have been configured so as to not be convex (the shortest path between two nodes within the zone passes outside the zone), or to leak (one or more boundary routers were not configured correctly), or to intersect in both area and address range.
o 错误配置很容易。很难检测已配置为不凸（区域内两个节点之间的最短路径通过区域外）或泄漏（一个或多个边界路由器未正确配置）或在区域和地址范围内相交的作用域。
These two barriers are addressed by this document. In particular, this document defines the Multicast Scope Zone Announcement Protocol (MZAP) which allows an entity to learn what scope zones it is within. Typically servers will cache the information learned from MZAP and can then provide this information to applications in a timely fashion upon request using other means, e.g., via MADCAP [9]. MZAP also provides diagnostic information to the boundary routers themselves that enables misconfigured scope zones to be detected.
本文件解决了这两个障碍。特别是，本文档定义了多播作用域公告协议（MZAP），该协议允许实体了解其所在的作用域。通常情况下，服务器将缓存从MZAP获取的信息，然后可以在请求时使用其他方式（例如，通过MADCAP）及时向应用程序提供这些信息[9]。MZAP还向边界路由器本身提供诊断信息，以检测配置错误的作用域。
The "Local Scope" is defined in RFC 2365 [1] and represents the smallest administrative scope larger than link-local, and the associated address range is defined as 239.255.0.0 to 239.255.255.255 inclusive (for IPv4, FF03::/16 for IPv6). RFC 2365 specifies:
“本地作用域”在RFC 2365[1]中定义，表示大于链路本地的最小管理作用域，关联的地址范围定义为239.255.0.0到239.255.255.255（对于IPv4，FF03:：/16对于IPv6）。RFC 2365规定：
"239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope is the minimal enclosing scope, and hence is not further divisible. Although the exact extent of a Local Scope is site dependent, locally scoped regions must obey certain topological constraints. In particular, a Local Scope must not span any other scope boundary. Further, a Local Scope must be completely contained within or equal to any larger scope. In the event that scope regions overlap in area, the area of overlap must be in its own Local Scope. This implies that any scope boundary is also a boundary for the Local Scope."
“239.255.0.0/16被定义为IPv4本地作用域。本地作用域是最小的封闭作用域，因此不可进一步分割。虽然本地作用域的确切范围取决于站点，但本地作用域必须遵守某些拓扑约束。特别是，本地作用域不得跨越任何其他作用域边界。此外，本地作用域的范围必须与站点相关。本地作用域必须遵守某些拓扑约束cal范围必须完全包含在或等于任何较大范围内。如果范围区域在区域中重叠，则重叠区域必须在其自身的局部范围内。这意味着任何范围边界也是局部范围的边界。”
A multicast scope Zone Boundary Router (ZBR) is a router that is configured with a boundary for a particular multicast scope on one or more of its interfaces. Any interface that is configured with a boundary for any administrative scope zone MUST also have a boundary for the Local Scope zone, as described above.
多播作用域边界路由器（ZBR）是在其一个或多个接口上为特定多播作用域配置边界的路由器。如上所述，为任何管理范围区域配置了边界的任何接口也必须为本地范围区域配置边界。
Such routers SHOULD be configured so that the router itself is within the scope zone. This is shown in Figure 1(a), where router A is inside the scope zone and has the boundary configuration.
此类路由器的配置应确保路由器本身位于作用域内。这如图1（a）所示，其中路由器a位于作用域内，具有边界配置。
............ ................
. . +B+--> . *B+-->
. . / . / .
. * . + .
. <---+A*---+C+-> . <---+A+---*C+->
. + . . + .
. / . . / .
. zone X <-- . . zone X <-- .
.............. ..................
............ ................
. . +B+--> . *B+-->
. . / . / .
. * . + .
. <---+A*---+C+-> . <---+A+---*C+->
. + . . + .
. / . . / .
. zone X <-- . . zone X <-- .
.............. ..................
A,B,C - routers * - boundary interface + - interface
A,B,C - routers * - boundary interface + - interface
(a) Correct zone boundary (b) Incorrect zone boundary
(a) 正确的分区边界（b）不正确的分区边界
Figure 1: Administrative scope zone boundary placement
图1：管理范围分区边界放置
It is possible for the first router outside the scope zone to be configured with the boundary, as illustrated in Figure 1(b) where routers B and C are outside the zone and have the boundary configuration, whereas A does not, but this is NOT RECOMMENDED. This rule does not apply for Local Scope boundaries, but applies for all other boundary routers.
范围区域外的第一个路由器可以配置边界，如图1（b）所示，其中路由器b和C位于区域外并具有边界配置，而A不具有边界配置，但不建议这样做。此规则不适用于本地范围边界，但适用于所有其他边界路由器。
We next define the term "Zone ID" to mean the lowest IP address used by any ZBR for a particular zone for sourcing MZAP messages into that scope zone. The combination of this IP address and the first multicast address in the scope range serve to uniquely identify the scope zone. Each ZBR listens for messages from other ZBRs for the same boundary, and can determine the Zone ID based on the source addresses seen. The Zone ID may change over time as ZBRs come up and down.
接下来，我们将术语“区域ID”定义为任何ZBR为特定区域使用的最低IP地址，用于将MZAP消息来源到该作用域区域。此IP地址和作用域范围中的第一个多播地址的组合用于唯一标识作用域区域。每个ZBR侦听来自同一边界的其他ZBR的消息，并可以根据看到的源地址确定区域ID。随着ZBR的上下移动，区域ID可能会随时间变化。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
Constants used by this protocol are shown as [NAME-OF-CONSTANT], and summarized in section 7.
本协议使用的常数显示为[NAME-OF-CONSTANT]，并在第7节中汇总。
When a ZBR is configured correctly, it can deduce which side of the boundary is inside the scope zone and which side is outside it.
正确配置ZBR后，它可以推断边界的哪一侧在范围区域内，哪一侧在范围区域外。
Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for each zone for which it is configured as a boundary into that scope zone, containing information on the scope zone's address range, Zone ID, and textual names. These messages are multicast to the well-
这样的ZBR然后为每个区域发送周期性区域公告消息（ZAM），该区域被配置为进入该范围区域的边界，包含关于范围区域的地址范围、区域ID和文本名称的信息。这些消息被多播到井上-
known address [MZAP-LOCAL-GROUP] in the Local Scope, and are relayed across Local Scope boundaries into all Local Scope zones within the scope zone referred to by the ZAM message, as shown in Figure 2.
本地作用域中的已知地址[MZAP-LOCAL-GROUP]，并跨本地作用域边界中继到ZAM消息所指作用域区域内的所有本地作用域区域，如图2所示。
###########################
# Zone1 = Zone2 # ##### = large scope zone boundary
*E-----+--->A*-----+-x #
# | = v # ===== = Local Scope boundaries
# | ======*===*==#
# | = B F # ----> = path of ZAM originated by E
G*<-----+--->C*-> | ^ #
# v = <-+---+ # ABCDE = ZBRs
# D = Zone3 #
#######*################### * = boundary interface
###########################
# Zone1 = Zone2 # ##### = large scope zone boundary
*E-----+--->A*-----+-x #
# | = v # ===== = Local Scope boundaries
# | ======*===*==#
# | = B F # ----> = path of ZAM originated by E
G*<-----+--->C*-> | ^ #
# v = <-+---+ # ABCDE = ZBRs
# D = Zone3 #
#######*################### * = boundary interface
Figure 2: ZAM Flooding Example
图2:ZAM洪水实例
Any entity can thus listen on a single well-known group address and learn about all scopes in which it resides.
因此，任何实体都可以监听一个已知的组地址，并了解它所在的所有作用域。
MZAP also provides the ability to discover the nesting relationships between scope zones. Two zones are nested if one is comprised of a subset of the routers in the other, as shown in Figure 3.
MZAP还提供了发现作用域之间嵌套关系的能力。如果一个区域由另一个区域中的路由器子集组成，则两个区域是嵌套的，如图3所示。
+-----------+ +-----------+ +-------------+
| Zone 1 | | Zone 3 | | Zone 5 |
| +------+| | +------+ | .........|..
| |Zone 2|| | |Zone 4| | : Zone 6 | :
| +--A---+| | C | | D | :
+-----------+ +----+--B---+ +--------E----+ :
:..........:
+-----------+ +-----------+ +-------------+
| Zone 1 | | Zone 3 | | Zone 5 |
| +------+| | +------+ | .........|..
| |Zone 2|| | |Zone 4| | : Zone 6 | :
| +--A---+| | C | | D | :
+-----------+ +----+--B---+ +--------E----+ :
:..........:
(a) "Contained" (b) "Common Border" (c) "Overlap" Zone 2 nests Zone 4 nests Zones 5 and 6 inside Zone 1 inside Zone 3 do not nest
(a) “包含”（b）“公共边界”（c）“重叠”区域2嵌套区域4嵌套区域5和6在区域1内在区域3内不嵌套
Figure 3: Zone nesting examples
图3：区域嵌套示例
A ZBR cannot independently determine whether one zone is nested inside another. However, it can determine that one zone does NOT nest inside another. For example, in Figure 3:
ZBR无法独立确定一个分区是否嵌套在另一个分区内。但是，它可以确定一个分区不嵌套在另一个分区内。例如，在图3中：
o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2 from leaving zone 2. When ZBR A first receives a ZAM for zone 1, it then knows that zone 1 does not nest within zone 2, but it cannot, however, determine whether zone 2 nests within zone 1.
o ZBR A将通过1区的ZAMs，但将阻止2区的ZAMs离开2区。当ZBR A第一次收到区域1的ZAM时，它就知道区域1没有嵌套在区域2内，但是它无法确定区域2是否嵌套在区域1内。
o ZBR B acts as ZBR for both zones 3 and 4, and hence cannot determine if one is nested inside the other. However, ZBR C can determine that zone 3 does not nest inside zone 4 when it receives a ZAM for zone 3, since it is a ZBR for zone 4 but not zone 3.
o ZBR B充当3区和4区的ZBR，因此无法确定其中一个是否嵌套在另一个内。但是，ZBR C在收到区域3的ZAM时可以确定区域3没有嵌套在区域4内，因为它是区域4的ZBR，而不是区域3。
o ZBR D only acts as ZBR zone 6 and not 5, hence ZBR D can deduce that zone 5 does not nest inside zone 6 upon hearing a ZAM for zone 5. Similarly, ZBR E only acts as ZBR zone 5 and not 6, hence ZBR E can deduce that zone 6 does not nest inside zone 5 upon hearing a ZAM for zone 6.
o ZBR D仅充当ZBR区域6而不是5，因此ZBR D可以在听到区域5的ZAM时推断区域5不嵌套在区域6内。类似地，ZBR E仅充当ZBR区域5而不是6，因此ZBR E可以在听到区域6的ZAM时推断区域6不嵌套在区域5内。
The fact that ZBRs can determine that one zone does not nest inside another, but not that a zone does nest inside another, means that nesting must be determined in a distributed fashion. This is done by sending Not-Inside Messages (NIMs) which express the fact that a zone X is not inside a zone Y. Such messages are sent to the well-known [MZAP-LOCAL-GROUP] and are thus seen by the same entities listening to ZAM messages (e.g., MADCAP servers). Such entities can then determine the nesting relationship between two scopes based on a sustained absence of any evidence to the contrary.
ZBR可以确定一个分区不嵌套在另一个分区内，但不能确定一个分区嵌套在另一个分区内，这意味着必须以分布式方式确定嵌套。这是通过发送非内部消息（NIM）实现的，NIM表示区域X不在区域Y内。此类消息被发送到众所周知的[MZAP-LOCAL-GROUP]，因此被监听ZAM消息的相同实体（例如，MADCAP服务器）看到。然后，这些实体可以基于持续缺乏任何相反证据来确定两个作用域之间的嵌套关系。
Two other message types, Zone Convexity Messages (ZCMs) and Zone Limit Exceeded (ZLE) messages, are used only by routers, and enable them to compare their configurations for consistency and detect misconfigurations. These messages are sent to MZAP's relative address within the scope range associated with the scope zone to which they refer, and hence are typically not seen by entities other than routers. Their use in detecting specific misconfiguration scenarios will be covered in the next section.
另外两种消息类型，区域凸性消息（ZCM）和区域限制超出（ZLE）消息，仅由路由器使用，使它们能够比较其配置的一致性并检测错误配置。这些消息被发送到与它们所指的作用域区域关联的作用域范围内的MZAP的相对地址，因此除了路由器之外，其他实体通常看不到这些消息。下一节将介绍它们在检测特定错误配置场景中的使用。
Packet formats for all messages are described in Section 5.
第5节描述了所有消息的数据包格式。
When a boundary router first starts up, it uses its lowest IP address which it considers to be inside a given zone, and which is routable everywhere within the zone (for example, not a link-local address), as the Zone ID for that zone. It then schedules ZCM (and ZAM) messages to be sent in the future (it does not send them immediately). When a ZCM is received for the given scope, the sender is added to the local list of ZBRs (including itself) for that scope, and the Zone ID is updated to be the lowest IP address in the list. Entries in the list are eventually timed out if no further messages are received from that ZBR, such that the Zone ID will converge to the lowest address of any active ZBR for the scope.
当边界路由器第一次启动时，它使用它认为在给定区域内的最低IP地址作为该区域的区域ID，该地址可在区域内的任何地方路由（例如，不是链路本地地址）。然后，它会安排ZCM（和ZAM）消息在将来发送（不会立即发送）。当收到给定作用域的ZCM时，发送方将被添加到该作用域的ZBR本地列表（包括其自身），并且区域ID将更新为列表中的最低IP地址。如果没有从该ZBR接收到更多消息，则列表中的条目最终将超时，这样区域ID将聚合到作用域的任何活动ZBR的最低地址。
Note that the sender of ZAM messages MUST NOT be used in this way. This is because the procedure for detecting a leaky Local scope described in Section 4.3 below relies on two disjoint zones for the same scope range having different Zone IDs. If ZAMs are used to compute Zone IDs, then ZAMs leaking across a Local Scope boundary will cause the two zones to converge to the same Zone ID.
请注意，不得以这种方式使用ZAM消息的发送者。这是因为下文第4.3节所述的检测泄漏局部范围的程序依赖于具有不同区域ID的相同范围内的两个不相交区域。如果使用ZAMs计算区域ID，则ZAMs在局部范围边界泄漏将导致两个区域聚合到同一区域ID。
In this section, we cover how to detect various error conditions. If any error is detected, the router should attempt to alert a network administrator to the nature of the misconfiguration. The means to do this lies outside the scope of MZAP.
在本节中，我们将介绍如何检测各种错误条件。如果检测到任何错误，路由器应尝试提醒网络管理员错误配置的性质。这样做的方法不在MZAP的范围内。
Zone Convexity Messages (ZCMs) are used by routers to detect non-convex administrative scope zones, which are one possible misconfiguration. Non-convex scope zones can cause problems for applications since a receiver may never see administratively-scoped packets from a sender within the same scope zone, since packets travelling between them may be dropped at the boundary.
区域凸性消息（ZCM）被路由器用来检测非凸管理范围区域，这是一种可能的错误配置。非凸作用域区域可能会给应用程序带来问题，因为接收方可能永远看不到来自同一作用域区域内发送方的管理作用域数据包，因为在它们之间传输的数据包可能会在边界处丢弃。
In the example illustrated in Figure 4, the path between B and D goes outside the scope (through A and E). Here, Router B and Router C send ZCMs within a given scope zone for which they each have a boundary, with each reporting the other boundary routers of the zone from which they have heard. In Figure 4, Router D cannot see Router B's messages, but can see C's report of B, and so can conclude the zone is not convex.
在图4所示的示例中，B和D之间的路径超出了范围（通过A和E）。在这里，路由器B和路由器C在各自有边界的给定作用域区域内发送ZCM，并且各自报告其所听到的区域的其他边界路由器。在图4中，路由器D看不到路由器B的消息，但可以看到C对B的报告，因此可以得出区域不是凸的结论。
#####*####========
# B # = ##### = non-convex scope boundary
# |->A* =
# | # = ===== = other scope boundaries
# | ####*####
# | E # ----> = path of B's ZCM
# v D*
# C # * = boundary interface
#####*############
#####*####========
# B # = ##### = non-convex scope boundary
# |->A* =
# | # = ===== = other scope boundaries
# | ####*####
# | E # ----> = path of B's ZCM
# v D*
# C # * = boundary interface
#####*############
Figure 4: Non-convexity detection
图4：非凸性检测
Non-convex scope zones can be detected via three methods:
可通过三种方法检测非凸范围区域：
(1) If a ZBR is listed in ZCMs received, but the next-hop interface (according to the multicast RIB) towards that ZBR is outside the scope zone,
(1) 如果ZCR列在接收到的ZCMs中，但朝向该ZBR的下一跳接口（根据多播RIB）在作用域之外，
(2) If a ZBR is listed in ZCMs received, but no ZCM is received from that ZBR for [ZCM-HOLDTIME] seconds, as illustrated in Figure 4, or
(2) 如图4所示，如果ZBR列在收到的ZCMs中，但在[ZCM-HOLDTIME]秒内未收到来自该ZBR的ZCM，或
(3) ZAM messages can also be used in a manner similar to that for ZCMs in (1) above, as follows: if a ZAM is received from a ZBR on an interface inside a given scope zone, and the next-hop interface (according to the multicast RIB) towards that ZBR is outside the scope zone.
(3) ZAM消息也可以类似于上面（1）中ZCM的方式使用，如下所示：如果在给定作用域区域内的接口上从ZBR接收到ZAM，并且朝向该ZBR的下一跳接口（根据多播RIB）在作用域区域之外。
Zone Convexity Messages MAY also be sent and received by correctly configured ordinary hosts within a scope region, which may be a useful diagnostic facility that does not require privileged access.
区域凸性消息也可由范围区域内正确配置的普通主机发送和接收，这可能是一种不需要特权访问的有用诊断工具。
A "leaky" boundary is one which logically has a "hole" due to some router not having a boundary applied on an interface where one ought to exist. Hence, the boundary does not completely surround a piece of the network, resulting in scoped data leaking outside.
一个“泄漏”边界是一个逻辑上有一个“洞”的边界，因为一些路由器没有一个边界应用在一个应该存在的接口上。因此，边界不会完全包围网络的一部分，从而导致作用域数据泄漏到外部。
Leaky scope boundaries can be detected via two methods:
可通过两种方法检测泄漏范围边界：
(1) If it receives ZAMs originating inside the scope boundary on an interface that points outside the zone boundary. Such a ZAM message must have escaped the zone through a leak, and flooded back around behind the boundary. This is illustrated in Figure 5.
(1) 如果在指向分区边界外的接口上接收到源自范围边界内的ZAM。这样一条ZAM信息一定是通过泄漏逃出了该区域，并在边界后被淹没。这如图5所示。
=============#####*########
= Zone1 # A Zone2 # C = misconfigured router
= +---->*E v #
= | # B # ##### = leaky scope boundary
=======*=====#====*=======#
= D # | # ===== = other scope boundaries
= ^-----*C<--+ #
= Zone4 # Zone3 # ----> = path of ZAMs
=============##############
=============#####*########
= Zone1 # A Zone2 # C = misconfigured router
= +---->*E v #
= | # B # ##### = leaky scope boundary
=======*=====#====*=======#
= D # | # ===== = other scope boundaries
= ^-----*C<--+ #
= Zone4 # Zone3 # ----> = path of ZAMs
=============##############
Figure 5: ZAM Leaking
图5:ZAM泄漏
(2) If a Zone Length Exceeded (ZLE) message is received. The ZAM packet also contains a Zones Traveled Limit. If the number of Local Scope zones traversed becomes equal to the Zones Traveled Limit, a ZLE message is generated (the suppression mechanism for preventing implosion is described later in the Processing Rules section). ZLEs detect leaks where packets do not return to another part of the same scope zone, but instead reach other Local Scope zones far away from the ZAM originator.
(2) 如果收到超过区域长度（ZLE）消息。ZAM数据包还包含区域行程限制。如果经过的本地作用域的数量等于区域移动限制，则生成ZLE消息（用于防止内爆的抑制机制将在后面的处理规则部分中描述）。ZLE检测数据包不返回同一作用域区域的另一部分，而是到达远离ZAM发起人的其他本地作用域区域的泄漏。
In either case, the misconfigured router will be either the message origin, or one of the routers in the ZBR path list which is included in the message received (or perhaps a router on the path between two such ZBRs which ought to have been a ZBR itself).
在任何一种情况下，配置错误的路由器都将是消息源，或者是包含在接收到的消息中的ZBR路径列表中的一个路由器（或者可能是两个这样的ZBR之间的路径上的路由器，它应该是ZBR本身）。
A local scope is leaky if a router has an administrative scope boundary on some interface, but does not have a Local Scope boundary on that interface as specified in RFC 2365. This can be detected via the following method:
如果路由器在某个接口上具有管理作用域边界，但在该接口上没有RFC 2365中指定的本地作用域边界，则本地作用域是泄漏的。这可以通过以下方法进行检测：
o If a ZAM for a given scope is received by a ZBR which is a boundary for that scope, it compares the Origin's Scope Zone ID in the ZAM with its own Zone ID for the given scope. If the two do not match, this is evidence of a misconfiguration. Since a temporary mismatch may result immediately after a recent change in the reachability of the lowest-addressed ZBR, misconfiguration should be assumed only if the mismatch is persistent.
o 如果ZBR接收到给定范围的ZAM（ZBR是该范围的边界），则ZBR会将ZAM中原点的范围区域ID与其自身的给定范围区域ID进行比较。如果两者不匹配，这就是配置错误的证据。由于在最近最低寻址ZBR的可达性发生变化后，可能会立即导致临时不匹配，因此只有在不匹配持续存在的情况下，才应假设错误配置。
The exact location of the problem can be found by doing an mtrace [5] from the router detecting the problem, back to the ZAM origin, for any group within the address range identified by the ZAM. The router at fault will be the one reporting that a boundary was reached.
问题的确切位置可以通过从检测问题的路由器执行mtrace[5]，返回到ZAM原点，以查找ZAM标识的地址范围内的任何组。出现故障的路由器将是报告已到达边界的路由器。
Conflicting address ranges can be detected via the following method:
可以通过以下方法检测冲突的地址范围：
o If a ZBR receives a ZAM for a given scope, and the included start and end addresses overlap with, but are not identical to, the start and end addresses of a locally-configured scope.
o 如果ZBR收到给定作用域的ZAM，并且包含的起始地址和结束地址与本地配置的作用域的起始地址和结束地址重叠，但不相同。
Conflicting scope names can be detected via the following method:
可以通过以下方法检测冲突的作用域名称：
o If a ZBR is configured with a textual name for a given scope and language, and it receives a ZAM or ZCM with a name for the same scope and language, but the scope names do not match.
o 如果ZBR配置了给定范围和语言的文本名称，并且它接收到具有相同范围和语言名称的ZAM或ZCM，但范围名称不匹配。
Detecting either type of conflict above indicates that either the local router or the router originating the message is misconfigured. Configuration tools SHOULD strip white space from the beginning and end of each name to avoid accidental misconfiguration.
检测上述任一类型的冲突都表明本地路由器或发起消息的路由器配置错误。配置工具应该从每个名称的开头和结尾去除空白，以避免意外的错误配置。
All MZAP messages are sent over UDP, with a destination port of [MZAP-PORT] and an IPv4 TTL or IPv6 Hop Limit of 255.
所有MZAP消息都通过UDP发送，目标端口为[MZAP-port]，IPv4 TTL或IPv6跃点限制为255。
When sending an MZAP message referring to a given scope zone, a ZBR MUST use a source address which will have significance everywhere within the scope zone to which the message refers. For example, link-local addresses MUST NOT be used.
当发送引用给定作用域的MZAP消息时，ZBR必须使用一个源地址，该地址在消息引用的作用域内的任何地方都具有重要意义。例如，不能使用链接本地地址。
The common MZAP message header (which follows the UDP header), is shown below:
通用MZAP消息头（位于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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |B| PTYPE |Address Family | NameCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Origin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone End Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Zone Name-1 (variable length) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | Encoded Zone Name-N (variable length) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |B| PTYPE |Address Family | NameCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Origin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone End Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Zone Name-1 (variable length) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | Encoded Zone Name-N (variable length) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: The version defined in this document is version 0.
版本：此文档中定义的版本为版本0。
"Big" scope bit (B): If clear, indicates that the addresses in the scoped range are not subdividable, and that address allocators may utilize the entire range. If set, address allocators should not use the entire range, but should learn an appropriate sub-range via another mechanism (e.g., AAP [7]).
“大”作用域位（B）：如果清除，则表示作用域范围内的地址不可细分，并且地址分配器可以使用整个范围。如果设置，地址分配器不应使用整个范围，但应通过另一种机制（例如AAP[7]）学习适当的子范围。
Packet Type (PTYPE): The packet types defined in this document are: 0: Zone Announcement Message (ZAM) 1: Zone Limit Exceeded (ZLE) 2: Zone Convexity Message (ZCM) 3: Not-Inside Message (NIM)
数据包类型（PTYPE）：本文档中定义的数据包类型为：0:区域公告消息（ZAM）1:超出区域限制（ZLE）2:区域凸性消息（ZCM）3:非内部消息（NIM）
Address Family: The IANA-assigned address family number [10,11] identifying the address family for all addresses in the packet. The families defined for IP are: 1: IPv4 2: IPv6
地址族：IANA分配的地址族编号[10,11]，标识数据包中所有地址的地址族。为IP定义的系列为：1:IPv4 2:IPv6
Name Count: The number of encoded zone name blocks in this packet. The count may be zero.
名称计数：此数据包中编码的区域名称块的数量。计数可能为零。
Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) This gives the start address for the scope zone boundary. For example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then Zone Start Address is 239.1.0.0.
区域开始地址：32位（IPv4）或128位（IPv6）这为作用域区域边界提供了开始地址。例如，如果分区是239.1.0.0至239.1.0.255的边界，则分区起始地址为239.1.0.0。
Zone End Address: 32 bits (IPv4) or 128 bits (IPv6) This gives the ending address for the scope zone boundary. For example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255, then Zone End Address is 239.1.0.255.
区域结束地址：32位（IPv4）或128位（IPv6）这为作用域区域边界提供了结束地址。例如，如果分区是239.1.0.0至239.1.0.255的边界，则分区结束地址为239.1.0.255。
Message Origin: 32 bits (IPv4) or 128 bits (IPv6) This gives the IP address of the interface that originated the message.
消息来源：32位（IPv4）或128位（IPv6）这给出了发起消息的接口的IP地址。
Zone ID Address: 32 bits (IPv4) or 128 bits (IPv6) This gives the lowest IP address of a boundary router that has been observed in the zone originating the message. Together with Zone Start Address and Zone End Address, it forms a unique ID for the zone. Note that this ID is usually different from the ID of the Local Scope zone in which the origin resides.
区域ID地址：32位（IPv4）或128位（IPv6）这给出了在发起消息的区域中观察到的边界路由器的最低IP地址。它与区域开始地址和区域结束地址一起构成区域的唯一ID。请注意，此ID通常不同于原点所在的本地作用域的ID。
Encoded Zone Name:
+--------------------+
|D| Reserved (7 bits)|
+--------------------+
| LangLen (1 byte) |
+--------------------+-----------+
| Language Tag (variable size) |
+--------------------+-----------+
| NameLen (1 byte) |
+--------------------+-----------+
| Zone Name (variable size) |
+--------------------------------+
Encoded Zone Name:
+--------------------+
|D| Reserved (7 bits)|
+--------------------+
| LangLen (1 byte) |
+--------------------+-----------+
| Language Tag (variable size) |
+--------------------+-----------+
| NameLen (1 byte) |
+--------------------+-----------+
| Zone Name (variable size) |
+--------------------------------+
The first byte contains flags, of which only the high bit is defined. The other bits are reserved (sent as 0, ignored on receipt).
第一个字节包含标志，其中仅定义高位。其他位保留（作为0发送，接收时忽略）。
"Default Language" (D) bit: If set, indicates a preference that the name in the following language should be used if no name is available in a desired language.
“默认语言”（D）位：如果设置，则表示如果所需语言中没有可用名称，则应使用以下语言中的名称。
Language tag length (LangLen): 1 byte The length, in bytes, of the language tag.
语言标记长度（LangLen）：1字节语言标记的长度，以字节为单位。
Language Tag: (variable size) The language tag, such as "en-US", indicating the language of the zone name. Language tags are described in [6].
语言标记：（可变大小）语言标记，如“en-US”，表示区域名称的语言。语言标记如[6]所述。
Name Len: The length, in bytes, of the Zone Name field. The length MUST NOT be zero.
Name Len：区域名称字段的长度（以字节为单位）。长度不能为零。
Zone Name: multiple of 8 bits The Zone Name is an ISO 10646 character string in UTF-8 encoding [4] indicating the name given to the scope zone (eg: "ISI-West Site"). It should be relatively short and MUST be less than 256 bytes in length. White space SHOULD be stripped from the beginning and end of each name before encoding, to avoid accidental conflicts.
区域名称：8位的倍数区域名称是一个UTF-8编码的ISO10646字符串[4]，表示范围区域的名称（例如：“ISI West Site”）。它应该相对较短，长度必须小于256字节。在编码之前，应该从每个名称的开头和结尾去除空白，以避免意外冲突。
Padding (if needed): The end of the MZAP header is padded with null bytes until it is 4-byte aligned.
Padding（如果需要）：MZAP头的末尾用空字节填充，直到对齐4字节为止。
A Zone Announcement Message has PTYPE=0, and is periodically sent by a ZBR for each scope for which it is a boundary, EXCEPT:
区域公告消息的PTYPE=0，由ZBR定期为其作为边界的每个作用域发送，但以下情况除外：
o the Local Scope
o 局部范围
o the Link-local scope
o 链接本地范围
The format of a Zone Announcement Message is shown below:
区域公告消息的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are defined as follows:
这些字段定义如下：
Zones Traveled (ZT): 8 bits This gives the number of Local Zone IDs contained in this message path.
已移动区域（ZT）：8位这表示此消息路径中包含的本地区域ID的数量。
Zones Traveled Limit (ZTL): 8 bits This gives the limit on number of local zones that the packet can traverse before it MUST be dropped. A value of 0 indicates that no limit exists.
Zones Traveled Limit（ZTL）：8位这给出了在必须丢弃数据包之前，数据包可以穿越的本地区域的数量限制。值为0表示不存在限制。
Hold Time: The time, in seconds, after which the receiver should assume the scope no longer exists, if no subsequent ZAM is received. This should be set to [ZAM-HOLDTIME].
保持时间：如果没有接收到后续ZAM，则接收器应假定范围不再存在的时间（以秒为单位）。这应该设置为[ZAM-HOLDTIME]。
Zone Path: multiple of 64 bits (IPv4) or 256 bits (IPv6) The zone path is a list of Local Zone ID Addresses (the Zone ID Address of a local zone) through which the ZAM has passed, and IP addresses of the router that forwarded the packet. The origin router fills in the "Local Zone ID Address 0" field when sending the ZAM. Every Local Scope router that forwards the ZAM across a Local Scope boundary MUST add the Local Zone ID Address of the local zone that the packet of the zone into which the message is being forwarded, and its own IP address to the end of this list, and increment ZT accordingly. The zone path is empty which the ZAM is first sent.
区域路径：64位（IPv4）或256位（IPv6）的倍数区域路径是ZAM通过的本地区域ID地址（本地区域的区域ID地址）和转发数据包的路由器的IP地址的列表。发送ZAM时，原始路由器填写“本地区域ID地址0”字段。每个通过本地作用域边界转发ZAM的本地作用域路由器必须将消息转发到的区域的数据包所在的本地区域的本地区域ID地址及其自己的IP地址添加到此列表的末尾，并相应地增加ZT。第一次发送ZAM的区域路径为空。
The format of a ZLE is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of a ZLE is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields are copied from the ZAM, except PTYPE which is set to one.
所有字段均从ZAM复制，但PTYPE设置为1的字段除外。
A Zone Announcement Message has PTYPE=2, and is periodically sent by a ZBR for each scope for which it is a boundary (except the Link-local scope). Note that ZCM's ARE sent in the Local Scope.
区域公告消息的PTYPE=2，由ZBR为其作为边界的每个作用域（链路本地作用域除外）定期发送。请注意，ZCM是在本地范围内发送的。
Unlike Zone Announcement Messages which are sent to the [MZAP-LOCAL-GROUP], Zone Convexity Messages are sent to the [ZCM-RELATIVE-GROUP] in the scope zone itself. The format of a ZCM is shown below:
与发送到[MZAP-LOCAL-GROUP]的区域公告消息不同，区域凸性消息发送到作用域本身中的[ZCM-RELATIVE-GROUP]。ZCM的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZNUM | unused | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZBR Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZBR Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZNUM | unused | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZBR Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZBR Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
字段如下所示：
Number of ZBR addresses (ZNUM): 8 bits This field gives the number of ZBR Addresses contained in this message.
ZBR地址数（ZNUM）：8位此字段给出此消息中包含的ZBR地址数。
Hold Time: The time, in seconds, after which the receiver should assume the sender is no longer reachable, if no subsequent ZCM is received. This should be set to [ZCM-HOLDTIME].
保持时间：如果没有接收到后续ZCM，则在该时间之后，接收方应假定无法再联系到发送方，以秒为单位。这应该设置为[ZCM-HOLDTIME]。
ZBR Address: 32 bits (IPv4) or 128 bits (IPv6) These fields give the addresses of the other ZBRs from which the Message Origin ZBR has received ZCMs but whose hold time has not expired. The router should include all such addresses which fit in the packet, preferring those which it has not included recently if all do not fit.
ZBR地址：32位（IPv4）或128位（IPv6）这些字段提供其他ZBR的地址，消息源ZBR已从这些ZBR接收ZCM，但其保持时间尚未过期。路由器应该包括所有适合该数据包的地址，如果所有地址都不适合，则优先考虑最近未包括的地址。
A Not-Inside Message (NIM) has PTYPE=3, and is periodically sent by a ZBR which knows that a scope X does not nest within another scope Y ("X not inside Y"):
非内部消息（NIM）的PTYPE=3，由ZBR定期发送，ZBR知道某个作用域X不嵌套在另一个作用域Y内（“X不在Y内”）：
The format of a Not-Inside Message is shown below:
非内部消息的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Not-Inside Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Not-Inside Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
字段如下所示：
MZAP Header: Header fields identifying the scope X. The Name Count may be 0.
MZAP标头：标识范围X的标头字段。名称计数可能为0。
Not-Inside Zone Start Address: 32 bits (IPv4) or 128 bits (IPv6) This gives the start address for the scope Y.
不在区域起始地址内：32位（IPv4）或128位（IPv6）这将给出作用域Y的起始地址。
Any host or application may join the [MZAP-LOCAL-GROUP] to listen for Zone Announcement Messages to build up a list of the scope zones that are relevant locally, and for Not-Inside Messages if it wishes to learn nesting information. However, listening to such messages is not the recommended method for regular applications to discover this information. These applications will normally query a local Multicast Address Allocation Server (MAAS) [3], which in turn listens to Zone Announcement Messages and Not-Inside Messages to maintain scope information, and can be queried by clients via MADCAP messages.
任何主机或应用程序都可以加入[MZAP-LOCAL-GROUP]来侦听区域公告消息，以建立与本地相关的作用域列表，如果希望了解嵌套信息，还可以侦听非内部消息。但是，对于常规应用程序来说，监听此类消息并不是发现这些信息的推荐方法。这些应用程序通常会查询本地多播地址分配服务器（MAAS）[3]，而本地多播地址分配服务器反过来会侦听区域公告消息而不是内部消息，以维护范围信息，并且客户端可以通过MADCAP消息进行查询。
An entity (including a MAAS) lacking any such information can only assume that it is within the Global Scope, and the Local Scope, both of which have well-known address ranges defined in [1].
缺少任何此类信息的实体（包括MAA）只能假设其位于全局范围和局部范围内，这两者都具有[1]中定义的众所周知的地址范围。
An internal entity (e.g., an MAAS) receiving a ZAM will parse the information that is relevant to it, such as the address range, and the names. An address allocator receiving such information MUST also use the "B" bit to determine whether it can add the address range to the set of ranges from which it may allocate addresses (specifically, it may add them only if the bit is zero). Even if the bit is zero, an MAAS SHOULD still store the range information so that clients who use relative- addresses can still obtain the ranges by requesting them from the MAAS.
接收ZAM的内部实体（如MAAS）将解析与其相关的信息，如地址范围和名称。接收此类信息的地址分配器还必须使用“B”位来确定是否可以将地址范围添加到可分配地址的范围集合中（具体而言，仅当位为零时，它可以添加地址范围）。即使位为零，MAAS仍应存储范围信息，以便使用相对地址的客户端仍可通过向MAAS请求来获取范围。
An internal entity (e.g., an MAAS) should assume that X nests within Y if:
内部实体（如MAA）应假设X嵌套在Y中，如果：
a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME] seconds ago, AND
a) 至少在[NIM-HOLDTIME]秒前，它第一次听到X和Y的ZAM，并且
b) it has not heard a NIM indicating that "X not inside Y" for at least [NIM-HOLDTIME] seconds.
b) 它至少在[NIM-HOLDTIME]秒内没有听到NIM指示“X不在Y内”。
Each ZBR should send a Zone Announcement Message for each scope zone for which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of [ZAM-INTERVAL] each time to avoid message synchronisation.
每个ZBR应每[ZAM-INTERVAL]秒发送一条其作为边界的每个范围区域的区域公告消息，每次发送+/-30%的[ZAM-INTERVAL]，以避免消息同步。
The ZAM packet also contains a Zones Traveled Limit (ZTL). If the number of Local Zone IDs in the ZAM path becomes equal to the Zones Traveled Limit, the packet will be dropped. The ZTL field is set when the packet is first sent, and defaults to 32, but can be set to a lower value if a network administrator knows the expected size of the zone.
ZAM数据包还包含区域行程限制（ZTL）。如果ZAM路径中的本地区域ID数量等于区域移动限制，则数据包将被丢弃。ZTL字段在第一次发送数据包时设置，默认为32，但如果网络管理员知道区域的预期大小，则可以将其设置为较低的值。
When a ZBR receives a ZAM for some scope zone X, it uses the following rules.
当ZBR收到某个范围区域X的ZAM时，它使用以下规则。
If the local ZBR does NOT have any configuration for scope X:
如果本地ZBR没有范围X的任何配置：
(1) Check to see if the included start and end addresses overlap with, but are not identical to, the start and end addresses of any locally-configured scope Y, and if so, signal an address range conflict to a local administrator.
(1) 检查包含的起始地址和结束地址是否与任何本地配置的作用域Y的起始地址和结束地址重叠但不相同，如果是，则向本地管理员发出地址范围冲突的信号。
(2) Create a local "X not inside" state entry, if such an entry does not already exist. The ZBR then restarts the entry's timer at [ZAM-HOLDTIME]. Existence of this state indicates that the ZBR knows that X does not nest inside any scope for which it is a boundary. If the entry's timer expires (because no more ZAMs for X are heard for [ZAM-HOLDTIME]), the entry is deleted.
(2) 如果本地“X不在内部”状态条目不存在，则创建该条目。然后，ZBR在[ZAM-HOLDTIME]重新启动条目的计时器。此状态的存在表明ZBR知道X不嵌套在它作为边界的任何范围内。如果条目的计时器过期（因为[ZAM-HOLDTIME]不再听到X的ZAM），则该条目将被删除。
If the local ZBR does have configuration for scope X:
如果本地ZBR没有范围X的配置：
(1) If the ZAM originated from OUTSIDE the scope (i.e., received over a boundary interface for scope X):
(1) 如果ZAM来自范围外（即通过范围X的边界接口接收）：
a) If the Scope Zone ID in the ZAM matches the ZBR's own Scope Zone ID, then signal a leaky scope misconfiguration.
a) 如果ZAM中的作用域ID与ZBR自己的作用域ID匹配，则表示存在泄漏的作用域错误配置。
b) Drop the ZAM (perform no further processing below). For example, router G in Figure 2 will not forward the ZAM. This rule is primarily a safety measure, since the placement of G in Figure 2 is not a recommended configuration, as discussed earlier.
b) 放下ZAM（不执行下面的进一步处理）。例如，图2中的路由器G不会转发ZAM。该规则主要是一种安全措施，因为如前所述，图2中G的位置不是推荐的配置。
2) If the ZAM originated from INSIDE the scope:
2) 如果ZAM来自范围内：
a) If the next-hop interface (according to the multicast RIB) towards the Origin is outside the scope zone, then signal a non- convexity problem.
a) 如果朝向原点的下一跳接口（根据多播RIB）在作用域之外，则表明存在非凸性问题。
b) If the Origin's Scope Zone ID in the ZAM does not match the Scope Zone ID kept by the local ZBR, and this mismatch continues to occur, then signal a possible leaky scope warning.
b) 如果ZAM中原点的范围区域ID与本地ZBR保留的范围区域ID不匹配，并且这种不匹配继续发生，则发出可能的范围泄漏警告信号。
c) For each textual name in the ZAM, see if a name for the same scope and language is locally-configured; if so, but the scope names do not match, signal a scope name conflict to a local administrator.
c) 对于ZAM中的每个文本名称，查看是否本地配置了相同范围和语言的名称；如果是，但作用域名称不匹配，则向本地管理员发出作用域名称冲突的信号。
d) If the ZAM was received on an interface which is NOT a Local Scope boundary, and the last Local Zone ID Address in the path list is 0, the ZBR fills in the Local Zone ID Address of the local zone from which the ZAM was received.
d) 如果在非本地范围边界的接口上接收到ZAM，且路径列表中的最后一个本地区域ID地址为0，则ZBR将填写接收到ZAM的本地区域的本地区域ID地址。
If a ZAM for the same scope (as identified by the origin Zone ID and first multicast address) was received in the last [ZAM-DUP-TIME] seconds, the ZAM is then discarded. Otherwise, the ZAM is cached for at least [ZAM-DUP-TIME] seconds. For example, when router C in Figure 2 receives the ZAM via B, it will not be forwarded, since it has just forwarded the ZAM from E.
如果在最后[ZAM-DUP-TIME]秒内收到相同作用域的ZAM（由源区域ID和第一个多播地址标识），则会丢弃该ZAM。否则，ZAM将被缓存至少[ZAM-DUP-TIME]秒。例如，当图2中的路由器C通过B接收ZAM时，它不会被转发，因为它刚刚从E转发了ZAM。
The Zones Travelled count in the message is then incremented, and if the updated count is equal to or greater than the ZTL field, schedule a ZLE to be sent as described in the next subsection and perform no further processing below.
消息中的区域移动计数随后增加，如果更新的计数等于或大于ZTL字段，则按照下一小节中的说明安排发送ZLE，并且不执行下面的进一步处理。
If the Zone ID of the Local Scope zone in which the ZBR resides is not already in the ZAM's path list, then the ZAM is immediately re-originated within the Local Scope zone. It adds its own address and the Zone ID of the Local Scope zone into which the message is being forwarded to the ZAM path list before doing so. A ZBR receiving a ZAM with a non-null path list MUST NOT forward that ZAM back into a Local Scope zone that is contained in the path list. For example, in Figure 2, router F, which did not get the ZAM via A due to packet loss, will not forward the ZAM from B back into Zone 2 since the path list has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears.
如果ZBR所在的本地范围区域的区域ID不在ZAM的路径列表中，则ZAM将立即在本地范围区域内重新启动。在执行此操作之前，它会将自己的地址和消息转发到ZAM路径列表的本地作用域的区域ID添加到ZAM路径列表中。接收具有非空路径列表的ZAM的ZBR不得将该ZAM转发回路径列表中包含的本地作用域。例如，在图2中，由于数据包丢失而没有通过A获得ZAM的路由器F不会将ZAM从B转发回区域2，因为路径列表有{（E，1），（A，2），（B，3）}，因此区域2已经出现。
In addition, the ZBR re-originates the ZAM out each interface with a Local Scope boundary (except that it is not sent back out the interface over which it was received, nor is it sent into any local scope zone whose ID is known and appears in the path list). In each such ZAM re-originated, the ZBR adds its own IP address to the path
此外，ZBR使用本地作用域边界重新启动ZAM out每个接口（除了它不会发送回接收它的接口，也不会发送到ID已知且出现在路径列表中的任何本地作用域区域）。在每一个这样的ZAM中，ZBR都会将自己的IP地址添加到路径中
list, as well as the Zone ID Address of the Local Scope Zone into which the ZAM is being sent, or 0 if the ID is unknown. (For example, if the other end of a point-to-point link also has a boundary on the interface, then the link has no Local Scope Zone ID.)
列表，以及将ZAM发送到的本地作用域的区域ID地址，如果ID未知，则为0。（例如，如果点到点链接的另一端在接口上也有边界，则该链接没有本地作用域ID。）
This packet is sent by a local-zone boundary router that would have exceeded the Zone Traveled Limit if it had forwarded a ZAM packet. To avoid ZLE implosion, ZLEs are multicast with a random delay and suppressed by other ZLEs. It is only scheduled if at least [ZLE-MIN-INTERVAL] seconds have elapsed since it previously sent a ZLE to any destination. To schedule a ZLE, the router sets a random delay timer within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to the [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs. If any are received before the random delay timer expires, the timer is cleared and the ZLE is not sent. If the timer expires, the router sends a ZLE to the [MZAP-RELATIVE-GROUP] within the indicated scope.
此数据包由本地区域边界路由器发送，如果转发了ZAM数据包，该路由器将超过区域移动限制。为了避免ZLE内爆，ZLE是具有随机延迟的多播，并被其他ZLE抑制。只有在之前向任何目的地发送ZLE后至少经过[ZLE-MIN-INTERVAL]秒的情况下，才会安排此操作。为了调度ZLE，路由器在间隔[ZLE-SUPPRESSION-interval]内设置一个随机延迟计时器，并在包含的范围内侦听其他ZLE的[MZAP-RELATIVE-GROUP]。如果在随机延迟定时器到期之前收到任何信号，则定时器被清除，ZLE不发送。如果计时器过期，路由器将向指示范围内的[MZAP-RELATIVE-GROUP]发送ZLE。
The method used to choose a random delay (T) is as follows:
用于选择随机延迟（T）的方法如下：
Choose a random value X from the uniform random interval [0:1]
Let C = 256
Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)
Choose a random value X from the uniform random interval [0:1]
Let C = 256
Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)
This equation results in an exponential random distribution which ensures that close to one ZBR will respond. Using a purely uniform distribution would begin to exhibit scaling problems as the number of ZBRs rose. Since ZLEs are only suppressed if a duplicate ZLE arrives before the time chosen, two routers choosing delays which differ by an amount less than the propagation delay between them will both send messages, consuming excess bandwidth. Hence it is desirable to minimize the number of routers choosing a delay close to the lowest delay chosen, and an exponential distribution is suitable for this purpose.
该方程导致指数随机分布，确保接近一个ZBR将响应。随着ZBR数量的增加，使用纯均匀分布将开始出现缩放问题。由于ZLE仅在重复的ZLE在所选时间之前到达时才被抑制，因此两个路由器选择的延迟量之差小于它们之间的传播延迟，这两个路由器都将发送消息，消耗多余的带宽。因此，期望最小化选择接近所选择的最低延迟的路由器的数量，并且指数分布适合于此目的。
A router SHOULD NOT send more than one Zone Limit Exceeded message every [ZLE-MIN-INTERVAL] regardless of destination.
无论目的地为何，路由器每[ZLE-MIN-INTERVAL]发送的超出区域限制消息不应超过一条。
When a router receives a ZLE, it performs the following actions:
当路由器收到ZLE时，它将执行以下操作：
(1) If the router has a duplicate ZLE message scheduled to be sent, it unschedules its own message so another one will not be sent.
(1) 如果路由器计划发送一条重复的ZLE消息，它会取消自己的消息计划，这样就不会发送另一条消息。
(2) If the ZLE contains the router's own address in the Origin field, it signals a leaky scope misconfiguration.
(2) 如果ZLE在“源”字段中包含路由器自己的地址，则表示泄漏范围配置错误。
Each ZBR should send a Zone Convexity Message (ZCM) for each scope zone for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30% of [ZCM-INTERVAL] each time to avoid message synchronisation.
每个ZBR应每[ZCM-INTERVAL]秒发送一次其作为边界的每个作用域的区域凸性消息（ZCM），每次为[ZCM-INTERVAL]的+/-30%，以避免消息同步。
ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. (For example, if the scope range is 239.1.0.0 to 239.1.0.255, then these messages should be sent to 239.1.0.252.) As these are not Locally-Scoped packets, they are simply multicast across the scope zone itself, and require no path to be built up, nor any special processing by intermediate Local Scope ZBRs.
ZCM被发送到作用域本身中的[ZCM-RELATIVE-GROUP]。（例如，如果作用域范围是239.1.0.0到239.1.0.255，那么这些消息应该发送到239.1.0.252。）由于这些不是本地作用域的数据包，它们只是跨作用域本身的多播，不需要建立路径，也不需要中间本地作用域ZBR进行任何特殊处理。
When a ZCM is received for a given scope X, on an interface which is inside the scope, it follows the rules below:
当在范围内的接口上接收到给定范围X的ZCM时，它遵循以下规则：
(1) The Origin is added to the local list of ZBRs (including itself) for that scope, and the Zone ID is updated to be the lowest IP address in the list. The new entry is scheduled to be timed out after [ZCM-HOLDTIME] if no further messages are received from that ZBR, so that the Zone ID will converge to the lowest address of any active ZBR for the scope.
(1) 原点被添加到该范围的ZBR（包括其本身）的本地列表中，并且区域ID被更新为列表中的最低IP地址。如果没有收到来自ZBR的进一步消息，则新条目将在[ZCM-HOLDTIME]之后超时，以便区域ID将聚合到作用域的任何活动ZBR的最低地址。
(2) If a ZBR is listed in ZCMs received, but the next-hop interface (according to the multicast RIB) towards that ZBR is outside the scope zone, or if no ZCM is received from that ZBR for [ZCM-HOLDTIME] seconds, as in the example in Figure 4, then signal a non-convexity problem.
(2) 如果ZBR列在接收到的ZCMs中，但朝向该ZBR的下一跳接口（根据多播RIB）在作用域之外，或者如果[ZCM-HOLDTIME]秒内没有从该ZBR接收到ZCM，如图4中的示例所示，则发出非凸性问题的信号。
(3) For each textual name in the ZCM, see if a name for the same scope and language is locally-configured; if so, but the scope names do not match, signal a scope name conflict to a local administrator.
(3) 对于ZCM中的每个文本名称，查看是否本地配置了相同范围和语言的名称；如果是，但作用域名称不匹配，则向本地管理员发出作用域名称冲突的信号。
Periodically, for each scope zone Y for which it is a boundary, a router originates a Not-Inside Message (NIM) for each "X not inside" entry it has created when receiving ZAMs. Like a ZAM, this message is multicast to the address [MZAP-LOCAL-GROUP] from one of its interfaces inside Y.
对于作为边界的每个作用域Y，路由器定期为其在接收ZAMs时创建的每个“X Not INDER”条目生成Not INDER消息（NIM）。与ZAM一样，此消息从Y中的一个接口多播到地址[MZAP-LOCAL-GROUP]。
Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL] seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization.
每个ZBR应每隔[NIM-INTERVAL]秒发送一条非内部消息，即[NIM-INTERVAL]的+/-30%，以避免消息同步。
When a ZBR receives a NIM saying that "X is not inside Y", it is forwarded, unmodified, in a manner similar to ZAMs:
当ZBR收到NIM，表示“X不在Y内”时，它将以类似于ZAMs的方式被转发，未经修改：
(1) If the NIM was received on an interface with a boundary for either X or Y, the NIM is discarded.
(1) 如果NIM是在具有X或Y边界的接口上接收的，则NIM将被丢弃。
(2) Unlike ZAMs, if the NIM was not received on the interface towards the message origin (according to the Multicast RIB), the NIM is discarded.
(2) 与ZAMs不同，如果NIM没有在面向消息源的接口上接收（根据多播RIB），NIM将被丢弃。
(3) If a NIM for the same X and Y (where each is identified by its first multicast address) was received in the last [ZAM-DUP-TIME] seconds, the NIM is not forwarded.
(3) 如果在最后[ZAM-DUP-TIME]秒内收到相同X和Y的NIM（其中每个都由其第一个多播地址标识），则不会转发NIM。
(4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.
(4) 否则，NIM将被缓存至少[ZAM-DUP-TIME]秒。
(5) The ZBR then re-originates the NIM (i.e., with the original UDP payload) into each local scope zone in which it has interfaces, except that it is not sent back into the local scope zone from which the message was received, nor is it sent out any interface with a boundary for either X or Y.
(5) 然后，ZBR将NIM（即，使用原始UDP有效负载）重新发起到其具有接口的每个本地作用域区域，但不会将其发送回接收消息的本地作用域区域，也不会将其发送到具有X或Y边界的任何接口。
[MZAP-PORT]: The well-known UDP port to which all MZAP messages are sent. Value: 2106.
[MZAP-PORT]：将所有MZAP消息发送到的众所周知的UDP端口。价值：2106。
[MZAP-LOCAL-GROUP]: The well-known group in the Local Scope to which ZAMs are sent. All Multicast Address Allocation servers and Zone Boundary Routers listen to this group. Value: 239.255.255.252 for IPv4.
[MZAP-LOCAL-GROUP]：将ZAM发送到的本地作用域中的知名组。所有多播地址分配服务器和区域边界路由器都侦听此组。值：对于IPv4，为239.255.255.252。
[ZCM-RELATIVE-GROUP]: The relative group in each scope zone, to which ZCMs are sent. A Zone Boundary Router listens to the relative group in each scope for which it is a boundary. Value: (last IP address in scope range) - 3. For example, in the Local Scope, the relative group is the same as the [MZAP-LOCAL-GROUP] address.
[ZCM-RELATIVE-GROUP]：每个作用域区域中的相对组，ZCM被发送到该相对组。区域边界路由器侦听其作为边界的每个作用域中的相对组。值：（作用域范围内的最后一个IP地址）-3。例如，在本地范围中，相对组与[MZAP-Local-group]地址相同。
[ZAM-INTERVAL]: The interval at which a Zone Boundary Router originates Zone Announcement Messages. Default value: 600 seconds (10 minutes).
[ZAM-INTERVAL]：区域边界路由器发起区域公告消息的时间间隔。默认值：600秒（10分钟）。
[ZAM-HOLDTIME]: The holdtime to include in a ZAM. This SHOULD be set to at least 3 * [ZAM-INTERVAL]. Default value: 1860 seconds (31 minutes).
[ZAM-HOLDTIME]：要包含在ZAM中的保持时间。该值应设置为至少3*[ZAM-INTERVAL]。默认值：1860秒（31分钟）。
[ZAM-DUP-TIME]: The time interval after forwarding a ZAM, during which ZAMs for the same scope will not be forwarded. Default value: 30 seconds.
[ZAM-DUP-TIME]：转发ZAM后的时间间隔，在此期间，相同作用域的ZAM将不会被转发。默认值：30秒。
[ZCM-INTERVAL]: The interval at which a Zone Boundary Router originates Zone Convexity Messages. Default value: 600 seconds (10 minutes).
[ZCM-INTERVAL]：区域边界路由器发起区域凸性消息的间隔。默认值：600秒（10分钟）。
[ZCM-HOLDTIME]: The holdtime to include in a ZCM. This SHOULD be set to at least 3 * [ZCM-INTERVAL]. Default value: 1860 seconds (31 minutes).
[ZCM-HOLDTIME]：要包含在ZCM中的保持时间。这应设置为至少3*[ZCM-间隔]。默认值：1860秒（31分钟）。
[ZLE-SUPPRESSION-INTERVAL]: The interval over which to choose a random delay before sending a ZLE message. Default value: 300 seconds (5 minutes).
[ZLE-SUPPRESSION-INTERVAL]：在发送ZLE消息之前选择随机延迟的时间间隔。默认值：300秒（5分钟）。
[ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, regardless of destination. Default value: 300 seconds (5 minutes).
[ZLE-MIN-INTERVAL]：发送ZLE消息之间的最小间隔，不考虑目的地。默认值：300秒（5分钟）。
[NIM-INTERVAL]: The interval at which a Zone Boundary Router originates Not-Inside Messages. Default value: 1800 seconds (30 minutes).
[NIM-INTERVAL]：区域边界路由器发起非内部消息的间隔。默认值：1800秒（30分钟）。
[NIM-HOLDTIME]: The holdtime to include the state within a NIM. This SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value: 5460 (91 minutes)
[NIM-HOLDTIME]：在NIM中包含状态的保持时间。该值应至少设置为3*[NIM-INTERVAL]。默认值：5460（91分钟）
While unauthorized reading of MZAP messages is relatively innocuous (so encryption is generally not an issue), accepting unauthenticated MZAP messages can be problematic. Authentication of MZAP messages can be provided by using the IPsec Authentication Header (AH) [12].
虽然未经授权读取MZAP消息相对无害（因此加密通常不是问题），但接受未经验证的MZAP消息可能会有问题。可以使用IPsec身份验证头（AH）[12]提供MZAP消息的身份验证。
In the case of ZCMs and ZLEs, an attacker can cause false logging of convexity and leakage problems. It is likely that is would be purely an annoyance, and not cause any significant problem. (Such messages could be authenticated, but since they may be sent within large scopes, the receiver may not be able to authenticate a non-malicious sender.)
在ZCMs和ZLEs的情况下，攻击者可能导致凸度和泄漏问题的错误记录。这很可能是纯粹的烦恼，不会引起任何重大问题。（此类消息可以进行身份验证，但由于它们可能在较大范围内发送，因此接收方可能无法对非恶意发送方进行身份验证。）
ZAMs and NIMs, on the other hand, are sent within the Local Scope, where assuming a security relationship between senders and receivers is more practical.
另一方面，ZAMs和NIMs是在本地范围内发送的，在本地范围内，假设发送方和接收方之间存在安全关系更为实际。
In the case of NIMs, accepting unauthenticated messages can cause the false cancellation of nesting relationships. This would cause a section of the hierarchy of zones to flatten. Such a flattening would lessen the efficiency benefits afforded by the hierarchy but would not cause it to become unusable.
对于NIMs，接受未经验证的消息可能会导致嵌套关系的错误取消。这将导致分区层次的一部分变平。这种扁平化会降低等级制度带来的效率效益，但不会导致等级制度无法使用。
Accepting unauthenticated ZAM messages, however, could cause applications to believe that a scope zone exists when it does not. If these were believed, then applications may choose to use this non-existent administrative scope for their uses. Such applications would be able to communicate successfully, but would be unaware that their traffic may be traveling further than they expected. As a result, any application accepting unauthenticated ZAMs MUST only take scope names as a guideline, and SHOULD assume that their traffic sent to non-local scope zones might travel anywhere. The confidentiality of such traffic CANNOT be assumed from the fact that it was sent to a scoped address that was discovered using MZAP.
但是，接受未经验证的ZAM消息可能会导致应用程序认为作用域存在，而实际上它不存在。如果这些都是可信的，那么应用程序可以选择将这个不存在的管理范围用于它们的用途。这样的应用程序将能够成功地进行通信，但不知道它们的通信量可能比预期的要远。因此，任何接受未经验证的ZAM的应用程序都必须仅以作用域名称为指导，并且应该假设发送到非本地作用域区域的流量可能会在任何地方传播。这种通信的机密性不能从它被发送到使用MZAP发现的作用域地址这一事实来假设。
In addition, ZAMs are used to inform Multicast Address Allocation Servers (MAASs) of names and address ranges of scopes, and accepting unauthenticated ZAMs could result in false names being presented to users, and in wrong addresses being allocated to users. To counter this, MAAS's authenticate ZAMs as follows:
此外，ZAM用于通知多播地址分配服务器（MAAS）作用域的名称和地址范围，接受未经验证的ZAM可能会导致向用户提供错误的名称，并向用户分配错误的地址。为了应对这种情况，MAAS的认证程序如下：
(1) A ZBR signs all ZAMs it originates (using an AH).
(1) ZBR对其发起的所有ZAM进行签名（使用AH）。
(2) A ZBR signs a ZAM it relays if and only if it can authenticate the previous sender. A ZBR MUST still forward un-authenticated ZAMs (to provide leak detection), but should propagate an authenticated ZAM even if an un-authenticated one was received with the last [ZAM-DUP-TIME] seconds.
(2) 当且仅当ZBR能够验证前一个发送方时，ZBR才会对其中继的ZAM进行签名。ZBR仍必须转发未经验证的ZAM（以提供泄漏检测），但即使在最后[ZAM-DUP-TIME]秒内收到未经验证的ZAM，也应传播已验证的ZAM。
(3) A MAAS SHOULD be configured with the public key of the local zone in which it resides. A MAAS thus configured SHOULD ignore an unauthenticated ZAM if an authenticated one for the same scope has been received, and MAY ignore all unauthenticated ZAMs.
(3) MAAS应配置其所在本地区域的公钥。如果已收到同一作用域的已验证ZAM，则由此配置的MAA应忽略未经验证的ZAM，并可忽略所有未经验证的ZAM。
This document is a product of the MBone Deployment Working Group, whose members provided many helpful comments and suggestions, Van Jacobson provided some of the original ideas that led to this protocol. The Multicast Address Allocation Working Group also provided useful feedback regarding scope names and interactions with applications.
本文件是MBone部署工作组的产品，其成员提供了许多有用的意见和建议，Van Jacobson提供了导致本协议的一些原始想法。多播地址分配工作组还就作用域名称和与应用程序的交互提供了有用的反馈。
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[1] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", Work in Progress.
[3] Thaler，D.，Handley，M.和D.Estrin，“互联网多播地址分配架构”，正在进行中。
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[4] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[5] Fenner, W. and S. Casner, "A `traceroute' facility for IP Multicast", Work in Progress.
[5] Fenner，W.和S.Casner，“用于IP多播的`追踪路由'设施”，正在进行中。
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[6] Alvestrand，H.，“语言识别标签”，RFC1766，1995年3月。
[7] Handley, M. and S. Hanna. "Multicast Address Allocation Protocol (AAP)", Work in Progress.
[7] 汉德利，M.和S.汉娜。“多播地址分配协议（AAP）”，正在工作。
[8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998, Vancouver, Canada.
[8] Kermode，R.“带前向纠错的作用域混合自动重复请求（SHARQFEC）”，ACM SIGCOMM 981998年9月，加拿大温哥华。
[9] Hanna, S., Patel, B., and M. Shah. "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[9] 汉娜，S.，帕特尔，B.，和M.沙阿。“多播地址动态客户端分配协议（MADCAP）”，RFC2730，1999年12月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[11] IANA, "Address Family Numbers", http://www.isi.edu/in-
notes/iana/assignments/address-family-numbers
[11] IANA, "Address Family Numbers", http://www.isi.edu/in-
notes/iana/assignments/address-family-numbers
[12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[12] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
Mark Handley AT&T Center for Internet Research at ICSI 1947 Center St, Suite 600 Berkely, CA 94704 USA
马克·汉德利美国电话电报公司互联网研究中心，位于美国加利福尼亚州伯克利市ICSI 1947中心街600号套房，邮编94704
EMail: mjh@aciri.org
EMail: mjh@aciri.org
David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
David Thaler微软一路微软雷德蒙德，华盛顿州98052美国
EMail: dthaler@microsoft.com
EMail: dthaler@microsoft.com
Roger Kermode Motorola Australian Research Centre 12 Lord St, Botany, NSW 2019 Australia
Roger Kermode摩托罗拉澳大利亚研究中心，澳大利亚新南威尔士州植物学洛德街12号，2019年
EMail: Roger.Kermode@motorola.com
EMail: Roger.Kermode@motorola.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。