[要約] RFC 2776は、Multicast-Scope Zone Announcement Protocol（MZAP）に関する規格です。MZAPは、マルチキャストスコープゾーンのアナウンスメントを行うためのプロトコルであり、マルチキャストネットワークの管理を容易にすることを目的としています。
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.
Copyright（c）The Internet Society（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
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.
このような使用法をサポートするために、管理境界でのルーターは、1つ以上のインターフェイスごとのフィルター、または「マルチキャストスコープ境界」で構成されています。インターフェイスにこのような境界があるということは、インターフェイスのいずれかの方向に構成されたマルチキャストアドレスの範囲と一致するパケットを転送しないことを意味します。
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 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 一部のアプリケーションやサービスは、スコープ間のネスティング関係にも関心がある場合があります。たとえば、ネスティング関係の知識を使用して、「拡大するスコープ」検索を実行することができます。見つかった。研究では、ネストされたスコープがマルチキャスト修理トラフィックの局在に役立つことが示されています[8]。
Two barriers currently make administrative scoping difficult to deploy and use:
現在、2つの障壁により、管理スコーピングが展開して使用するのが難しくなっています。
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 不正行為は簡単です。凸にならないように構成されたスコープゾーンを検出することは困難です（ゾーン内の2つのノードの間の最短パスはゾーンの外側を通過します）、または漏れ（1つ以上の境界ルーターが正しく構成されていません）、またはエリアとアドレスの両方の範囲で交差します。
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.
これらの2つの障壁は、このドキュメントで対処されています。特に、このドキュメントでは、マルチキャストスコープゾーンアナウンスアナウンスプロトコル（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ローカルスコープであると定義されています。ローカルスコープは最小限の囲い範囲であり、したがって、それ以上分割されません。ローカルスコープの正確な範囲はサイトに依存しているが、局所的にスコープされた領域は特定のトポロジカルに従わなければならない。制約。特に、ローカルスコープは他の範囲の境界にまたがる必要はありません。さらに、ローカルスコープは、より大きなスコープ以内または等しい範囲内に完全に含まれている必要があります。独自のローカルスコープ。これは、範囲の境界がローカルスコープの境界でもあることを意味します。」
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）は、1つ以上のインターフェイスに特定のマルチキャストスコープの境界で構成されたルーターです。管理スコープゾーンの境界で構成されたインターフェイスには、上記のように、ローカルスコープゾーンの境界も必要です。
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 <-- .
.............. ..................
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」という用語を定義して、MZAPメッセージをそのスコープゾーンに調達するために特定のゾーンでzbrが使用する最低のIPアドレスを意味します。この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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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- 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.
このようなZBRは、スコープゾーンのアドレス範囲、ゾーンID、およびテキスト名に関する情報を含む、そのスコープゾーンへの境界として構成されている各ゾーンに定期的なゾーンアナウンスメッセージ（ZAM）を送信します。これらのメッセージは、図2に示すように、ZAMメッセージで言及されているスコープゾーン内のローカルスコープ境界を越えてローカルスコープ境界を越えて中継されており、ローカルスコープにある既知のアドレス[MZAP-Local-Group]にマルチキャストされています。。
###########################
# 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.
したがって、どのエンティティも、1つの有名なグループアドレスで聞くことができ、それが存在するすべてのスコープについて学ぶことができます。
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に示すように、1つが他のルーターのサブセットで構成されている場合、2つのゾーンがネストされます。
+-----------+ +-----------+ +-------------+
| 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) 「conted」（b） "common border"（c） "overlap"ゾーン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を通過しますが、ZAMSがゾーン2からのゾーン2を離れるのを防ぎます。ZBR Aがゾーン1のZAMを最初に受信すると、ゾーン1はゾーン2内にネストされないことがわかりますが、それはできませんが、できないことがわかります。ゾーン1内にゾーン2が巣を作るかどうかを判断します。
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を受け取るときにゾーン4を受け取るときにゾーン4内にネストされないと判断できます。これは、ゾーン3のZBRですが、ゾーン3ではなくZBRです。
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としてのみ機能し、ZBRは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.
ZBRSが1つのゾーンが別のゾーン内に巣を作らないことを判断できるという事実は、別のゾーンが別のゾーン内に巣を作ることではないことを意味します。これは、ゾーンXがゾーンY内にないという事実を表現する非インスサイドメッセージ（NIM）を送信することによって行われます。そのようなメッセージはよく知られている[MZAP-Local-Group]に送られ、したがって同じで見られます。ZAMメッセージを聞くエンティティ（例：MADCAPサーバー）。そのようなエンティティは、反対の証拠の持続的な不在に基づいて、2つのスコープ間の営巣関係を決定できます。
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.
他の2つのメッセージタイプ、ゾーンコンベクシティメッセージ（ZCMS）とゾーン制限を超えた（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が受信されると、送信者はそのスコープのZBRS（それ自体を含む）のローカルリストに追加され、ゾーン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を持つ同じスコープ範囲の2つの馬鹿げたゾーンに依存しているためです。ZAMがゾーンIDの計算に使用される場合、Zamsはローカルスコープ境界を越えて漏れているため、2つのゾーンが同じゾーン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
#####*############
Figure 4: Non-convexity detection
図4：非概念検出
Non-convex scope zones can be detected via three methods:
非凸範囲ゾーンは、3つの方法で検出できます。
(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) ZBRが受信したZCMSにリストされているが、そのZBRがスコープゾーンの外側にある次のホップインターフェイス（マルチキャストリブによる）がリストされている場合、
(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) ZBRが受信したZCMSにリストされているが、図4に示すように、[zcm-holdtime]秒間そのzbrから受信されない場合、または
(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）のZCMSと同様の方法で使用できます。次のように：ZAMが特定のスコープゾーン内のインターフェイス上のZBRから受信された場合、およびネクストホップインターフェイス（マルチキャストリブ）そのZBRに向かって、スコープゾーンの外側にあります。
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:
漏れやすいスコープ境界は、2つの方法で検出できます。
(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
=============##############
Figure 5: ZAM Leaking
図5：ザム漏れ
(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メッセージが生成されます（破裂を防ぐための抑制メカニズムは、処理ルールセクションで後で説明されます）。ZLESは、パケットが同じスコープゾーンの別の部分に戻らず、代わりに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パスリストのルーターの1つ（またはZBRであるべき2つの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 特定のスコープのZAMがそのスコープの境界であるZBRによって受信される場合、ZAMのOriginのスコープゾーンIDを、指定されたスコープの独自のゾーンIDと比較します。2つが一致しない場合、これは誤解の証拠です。一時的な不一致は、最低に抑制された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.
問題の正確な位置は、ZAMによって識別されたアドレス範囲内のすべてのグループに対して、問題を検出するルーターからMTRACE [5]を実行することで見つけることができます[5]。障害のあるルーターは、境界に到達したことを報告するものです。
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は、メッセージが参照するスコープゾーン内のどこにでも重要なソースアドレスを使用する必要があります。たとえば、Link-Localアドレスを使用しないでください。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+--------------------------------+
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.
名前レン：ゾーン名フィールドの長さ、バイト単位の長さ。長さはゼロではありません。
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ビットの倍数ゾーン名は、Scopeゾーンに与えられた名前を示すUTF-8エンコード[4]のISO 10646文字文字列です（例：「ISI-WESTサイト」）。比較的短く、長さ256バイト未満でなければなりません。偶発的な競合を避けるために、エンコードする前に各名前の最初と終わりから空白を剥がす必要があります。
Padding (if needed): The end of the MZAP header is padded with null bytes until it is 4-byte aligned.
パディング（必要に応じて）：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 Link-Local Scope
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ゾーンは制限された制限（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アドレスのリストですそれはパケットを転送しました。Originルーターは、ZAMを送信するときに「ローカルゾーンIDアドレス0」フィールドに記入します。ZAMをローカルスコープ境界に転送するすべてのローカルスコープルーターは、メッセージが転送されているゾーンのパケットと、このリストの最後まで独自のIPアドレスをローカルゾーンのローカルゾーンIDアドレスを追加する必要があります。それに応じて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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields are copied from the ZAM, except PTYPE which is set to one.
すべてのフィールドは、1つに設定されているPTYPEを除き、ZAMからコピーされます。
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リラートグループ]に送信されます。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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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がZCMを受信したが、その保持時間が期限切れになっていない他のZBRのアドレスを提供します。ルーターには、パケットに適合するすべてのアドレスを含める必要があり、すべてが収まらない場合は最近含まれていないアドレスを好みます。
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"):
Not-Insideメッセージ（NIM）にはPTYPE = 3があり、スコープXが別のスコープY（ "x not in y"）内にネストされないことを知っているzbrによって定期的に送信されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]に参加して、ゾーンアナウンスメッセージをリッスンして、ローカルに関連するスコープゾーンのリストを構築し、ネスト情報を学習したい場合はインチサイドメッセージではない場合があります。ただし、そのようなメッセージを聞くことは、定期的なアプリケーションがこの情報を発見するための推奨される方法ではありません。これらのアプリケーションは通常、ローカルマルチキャストアドレスArlocation Server（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:
内部エンティティ（たとえば、MAAS）は、xがy内に巣を作ることを想定する必要があります。
a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME] seconds ago, AND
a) 少なくとも[nim-holdtime]秒前にxとyの両方でzamsを最初に聞いた
b) it has not heard a NIM indicating that "X not inside Y" for at least [NIM-HOLDTIME] seconds.
b) 少なくとも[nim-holdtime]秒間「x xがy」であることを示すNIMを聞いたことはありません。
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]秒ごとに[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.
ScopeゾーンXに対してZBRが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 not insine」状態エントリを作成します。ZBRは[Zam-Holdtime]でエントリのタイマーを再起動します。この状態の存在は、ZBRがXが境界である範囲内に巣を作らないことを知っていることを示しています。エントリのタイマーが期限切れになった場合（XのZAMが[Zam-Holdtime]に対して聞こえないため）、エントリは削除されます。
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) next-Hopインターフェイス（マルチキャストリブによる）が原点に向かっている場合、スコープゾーンの外側にある場合、非凸の問題を示します。
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のOriginのスコープゾーン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（Origin Zone IDと最初のマルチキャストアドレスで識別される）が最後の[Zam-Dup-Time]秒で受信された場合、Zamは破棄されます。それ以外の場合、Zamは少なくとも[Zam-Dup-Time]秒間キャッシュされます。たとえば、図2のルーターCがBを介してZAMを受信する場合、ZAMをEから転送したばかりなので、転送されません。
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を追加します。null以外のパスリストを持つZAMを受信するZBRは、そのZAMをパスリストに含まれるローカルスコープゾーンに戻してはなりません。たとえば、図2では、パケット損失のためにAを介してZAMを取得しなかったルーターFは、パスリストに{（e、1）、（a、2）があるため、Zamをゾーン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 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.)
さらに、ZBRは、ローカルスコープ境界を持つ各インターフェイスを各インターフェイスを再配置します（受信したインターフェイスから送信されないことを除き、IDが既知で表示されているローカルスコープゾーンに送信されていません。パスリスト内）。このようなZAMが再生成するそれぞれで、ZBRはパスリストに独自のIPアドレスを追加し、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-MIN-INTERVAL]秒が経過した場合にのみスケジュールされます。ZLEをスケジュールするために、ルーターは間隔[ZLE-Suppression-interval]内でランダム遅延タイマーを設定し、他のZLEの付属範囲内で[MZAP相関グループ]に耳を傾けます。ランダム遅延タイマーの有効期限が切れる前に受信した場合、タイマーがクリアされ、ZLEが送信されません。タイマーの有効期限が切れた場合、ルーターは指定された範囲内で[MZAP相関グループ]にズルを送信します。
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)
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.
この方程式は、1つのZBRに近いことを保証する指数ランダム分布をもたらします。純粋に均一な分布を使用すると、ZBRの数が増加するにつれてスケーリングの問題が発生し始めます。ZLEは、選択された時間の前に重複したZLEが到着した場合にのみ抑制されるため、2つのルーターは、それらの間の伝播遅延よりも少ない量によって異なる遅延を選択します。したがって、選択した最低遅延に近い遅延を選択するルーターの数を最小限に抑えることが望ましいので、この目的には指数分布が適しています。
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にOriginフィールドにルーター自身のアドレスが含まれている場合、漏れやすいスコープの誤解を示します。
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-Interval]秒ごとに境界である[ZCM-Interval]秒ごとにゾーンコンベックスメッセージ（ZCM）を送信する必要があります。
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相関グループ]に送信されます。（たとえば、スコープ範囲が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) オリジンは、その範囲のZBRS（それ自体を含む）のローカルリストに追加され、ゾーン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がスコープゾーンの外側にある次のホップインターフェイス（マルチキャストリブによる）がスコープゾーンの外側にある場合、または[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について、ルーターは、ZAMを受信するときに作成した各「x not inthine」エントリの非インチサイドメッセージ（nim）を発信します。Zamのように、このメッセージはY内のインターフェイスの1つからアドレス[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]の30％[nim-interval]秒ごとにこのようなインサイドメッセージを送信する必要があります。
When a ZBR receives a NIM saying that "X is not inside Y", it is forwarded, unmodified, in a manner similar to ZAMs:
ZBRが「xはyにない」と言うnimを受け取ると、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がメッセージの原点に向かってインターフェイスで受信されなかった場合（マルチキャストリブによる）、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) 同じxとyのNIM（それぞれが最初のマルチキャストアドレスで識別される）が最後の[zam-dup time]秒で受信された場合、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相関グループ]：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-interval]に設定する必要があります。デフォルト値：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メッセージを受け入れることに問題があります。MZAPメッセージの認証は、IPSEC認証ヘッダー（AH）[12]を使用して提供できます。
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およびZLEの場合、攻撃者は凸性と漏れの問題の誤った伐採を引き起こす可能性があります。それは純粋に迷惑であり、重大な問題を引き起こさない可能性があります。（そのようなメッセージは認証される可能性がありますが、それらは大きなスコープ内で送信される可能性があるため、受信者は非悪質な送信者を認証できない場合があります。）
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はマルチキャストアドレス割り当てサーバー（MAASS）の名前とスコープ範囲のアドレス範囲に通知するために使用され、認知度のないZAMを受け入れると、ユーザーに誤った名前が提示され、間違ったアドレスがユーザーに割り当てられる可能性があります。これに対抗するために、MAASの認証ZAMSは次のとおりです。
(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は、以前の送信者を認証できる場合にのみ、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) MAAは、それが存在するローカルゾーンの公開鍵で構成する必要があります。このように構成された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 Deployment Working Groupの製品であり、そのメンバーは多くの有益なコメントと提案を提供し、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。and D. Estrin、「インターネットマルチキャストアドレスArlocation Architecture」、Work in Progress。
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[4] Yergeau、F。、「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。、「言語の識別のためのタグ」、RFC 1766、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。
[9] Hanna, S., Patel, B., and M. Shah. "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[9] Hanna、S.、Patel、B。、およびM. Shah。「マルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）」、RFC 2730、1999年12月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[11] IANA, "Address Family Numbers", http://www.isi.edu/in-notes/iana/assignments/address-family-numbers
[11] IANA、「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 Authentication Header」、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 Center St、Suite 600 Berkeley、CA 94704 USAのMark Handley AT＆Tセンターのインターネット研究センター
EMail: mjh@aciri.org
David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
David Thaler Microsoft One Microsoft Way Redmond、WA 98052 USA
EMail: dthaler@microsoft.com
Roger Kermode Motorola Australian Research Centre 12 Lord St, Botany, NSW 2019 Australia
ロジャーカーモードモトローラオーストラリア研究センター12ロードストリート、植物学、NSW 2019オーストラリア
EMail: Roger.Kermode@motorola.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。