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)
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
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で定義されている管理スコープのIPマルチキャストの使用は、[1]、パケットが交差しないようなパケットはマルチキャストアドレス（例えば、IPv4の239.255.255.255まで239.0.0.0）の特定の範囲に対処することを可能にします管理境界を設定し、また、そのようなアドレスがローカルに割り当てられるので、管理境界全体で一意である必要はありませんことができます。両方の論理命名のこの特性は、アドレスの再利用を可能にし、並びにそのようなアドレス割り当て、セッション広告、およびすべての組織内のローカルな意味を持つことが保証されている、よく知られたアドレスを使用するサービスの場所としてのインフラストラクチャサービスのための機能を提供します。
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 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.
それらは各スコープで使用するアドレスオフセット定数及び計算を適用することができるように、すべての範囲で（[1]で定義されるように）「相対的」マルチキャストアドレスを使用するOサービスは、それぞれの範囲で使用されるアドレスの範囲に興味を持っています。
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設定ミスが簡単です。 （ゾーン内の2つのノード間の最短経路は、ゾーンの外側を通過する）凸状にならないように構成されているスコープゾーンを検出することは困難である、または漏れ（一つ以上の境界ルータが正しく設定されなかった）、またはそれに地域とアドレス範囲の両方で交差します。
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から学習した情報をキャッシュし、その後、[9] MADCAPを介して、例えば、他の手段を使用して要求に応じて適時にアプリケーションにこの情報を提供することができます。 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]とリンクローカルよりも大きい最小の管理範囲を表し、および関連するアドレス範囲は、IPv4の、FF03のための239.255.255.255に239.255.0.0包括（:: / 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）は、そのインターフェイスの一つ以上の特定のマルチキャストスコープの境界に設定されたルータです。上記のように任意の管理スコープゾーンの境界が設定されている任意のインターフェイスはまた、ローカルスコープゾーンの境界がなければなりません。
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.
ルータ自体がスコープゾーン内にあるように、ルータは、構成されるべきです。これは、ルータAはスコープゾーン内にあり、境界構成を有し、図1（A）に示されています。
............ ................
. . +B+--> . *B+-->
. . / . / .
. * . + .
. <---+A*---+C+-> . <---+A+---*C+->
. + . . + .
. / . . / .
. zone X <-- . . zone X <-- .
.............. ..................
A,B,C - routers * - boundary interface + - interface
、B、C - ルーター* - 境界インタフェース+ - インターフェイス
(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がないのに対し、境界の構成を有している場合、これではないスコープゾーンの外側の第1のルータは、境界に構成することが可能ですお勧めします。このルールは、ローカルスコープの境界に適用されますが、他のすべての境界ルータに適用されていません。
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.
私たちは、次のようスコープゾーンにMZAPメッセージを調達するための特定のゾーンの任意のZBRで使用される最小のIPアドレスを意味する用語「ゾーンID」を定義します。このIPアドレスと範囲内の最初のマルチキャストアドレスの組み合わせが一意スコープゾーンを識別するのに役立つ範囲です。各ZBRは、同じ境界のために他のZBRsからのメッセージを聞き、見たソースアドレスに基づいてゾーンIDを決定することができます。 ZBRsが上下にくるようゾーン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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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、およびテキスト名の情報を含む、その範囲ゾーンに境界として構成されている各ゾーンの周期ゾーンアナウンスメッセージ（ZAMS）を送信します。これらのメッセージは、ローカルスコープの[MZAP-LOCAL-GROUP]周知のアドレスにマルチキャストされ、図2に示すように、スコープゾーンは、ZAMメッセージによって参照内のすべてのローカルスコープゾーンにローカルスコープの境界を越えて中継されます。
###########################
# 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に示すように、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）は、ゾーン3内のゾーン1内（B）「共通の境界」（C）「オーバーラップ」ゾーン2つの巣ゾーン4つの巣ゾーン5,6を「含まない」巣を行います
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を通過するが、ZBR Aは、第一のゾーン1のためのZAMを受信ゾーン2から出るゾーン2からZAMSを防止するであろう、しかし、そのゾーン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は、ゾーン4ではなくゾーン3 ZBRであるので、それは、ゾーン3についてZAMを受信した場合、そのゾーン3、ゾーン4内のネストしないかを決定することができます。
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 Dは、そのゾーンを推測することができ、したがって5はゾーン5のためのZAMを聞く際に、ゾーン6内のネストは同様に、ZBR EのみZBRゾーン5としない6として機能しない、ZBRゾーン6としない5として作用しますZBR Eゾーン6のためのZAMを聞いて、ゾーン5の内側6ネストないそのゾーンを推測することができます。
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にこのようなメッセージは、よく知られている[MZAP-LOCAL-GROUP]に送信され、従って、同じによって見られているゾーン内ではないという事実を発現し、内部メッセージ（のNIM）を送信することによって行われます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.
他の二つのメッセージタイプ、ゾーンコンベクシティメッセージ（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アドレスに更新されます。それ以上のメッセージはゾーンIDがスコープのための任意のアクティブZBRの最下位アドレスに収束するように、その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つの互いに素な領域に依存しているからです。 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.
ゾーンコンベクシティメッセージ（ZCMs）は、一つの可能な設定ミスである非凸管理スコープゾーンを検出するためにルータにより使用されます。それらの間で移動するパケットは、境界でドロップすることができるので、受信機は、同じスコープゾーン内の送信者から管理の有効範囲付きのパケットを見ることはないかもしれないので非凸スコープゾーンは、アプリケーションのための問題を引き起こす可能性があります。
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は、それぞれが、彼らが聞いているから、ゾーンの他の境界ルータを報告するとともに、それらのそれぞれが境界を持っている与えられたスコープゾーン内ZCMsを送ります。図4に、ルータDはルータBのメッセージを見ることができないが、BのCのレポートを見ることができ、したがってゾーンが凸ではないと結論することができます。
#####*####========
# 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）ZBRは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）ZBRがZCMsにリストされている場合、受信したが、図4に示すように何ZCMは、[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.
ZAMは、指定されたスコープのゾーン内部インターフェイス、および次ホップインターフェイス（上ZBRから受信された場合に次のように（3）ZAMメッセージは、（1）上記でZCMsと同様の方法でも使用することができますその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）それは、ゾーン境界の外側ポイントインターフェイス上スコープ境界内発信ZAMSを受信した場合。このような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：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メッセージが（爆縮を防止するための抑制機構は、後の処理ルールに記載されている）が生成されます。 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つのいずれかであろう（または、おそらく二つのそのようなZBRs間の経路上のルータは、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.
指定されたスコープのためのZAMは、そのスコープの境界であるZBRによって受信された場合、O、それはOriginの範囲ゾーンIDは、与えられた範囲のために、独自のゾーンIDとZAMで比較します。両者が一致しない場合、これは設定ミスの証拠です。一時的な不一致が最下位アドレス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によって識別アドレス範囲内の任意のグループに対して、バックZAM原点に、問題を検出ルータから[5] MTRACEを行うことによって求めることができます。障害のルータは、境界に達したことを報告していずれかになります。
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メッセージは、[MZAP-PORT]とIPv4 TTLまたは255のIPv6のホップ限界の宛先ポートと、UDPを介して送信されます。
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:
（UDPヘッダの後に続く）共通MZAPメッセージヘッダは、以下に示します。
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.
名前数：このパケットでエンコードされたゾーン名ブロックの数。カウントが0であってもよいです。
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.255に239.1.0.0のための境界である場合たとえば、その後、ゾーン開始アドレスは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.255に239.1.0.0のための境界である場合たとえば、その後、ゾーン終了アドレスは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フィールドの長さをバイト単位で、。長さがゼロであってはなりません。
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.
ゾーン名：ゾーン名はUTF-8エンコーディングにISO 10646文字列である8ビットの倍数[4]スコープゾーン（「ISI-ウエストサイト」など）に与えられた名前を示します。これは、比較的短くあるべきで、長さが256バイト未満でなければなりません。ホワイトスペースは、偶発的衝突を避けるために、エンコードする前にそれぞれの名前の最初と最後から取り除かれるべきです。
Padding (if needed): The end of the MZAP header is padded with null bytes until it is 4-byte aligned.
パディング（必要な場合）：これは、4バイト境界で整列されるまでMZAPヘッダの端部は、ヌルバイトでパディングされます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
これは、それがドロップされなければならない前に、パケットが通過できるローカルゾーンの数に制限を与える8ビット：ゾーンは制限（ZTL）を旅しました。 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」欄に記入します。ローカルゾーンのローカルゾーンのIDアドレスを追加する必要がありますローカルスコープの境界を越えてZAMを転送するすべてのローカルスコープルータというメッセージが転送されているにゾーン、およびリストの最後に、独自の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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相対-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ホールド時間経過していないが、ZCMsを受信し、そこから他のZBRsのアドレスを与えます。ルータは、すべてが適合しない場合、それは最近含まれていないものを好む、パケット内に収まるすべてのそのようなアドレスを含める必要があります。
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持っており、定期的にスコープXが別のスコープY（「Xません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.
ない-Insideは、ゾーンスタート住所：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.
任意のホストやアプリケーションが、ネストの情報を学ぶことを希望する場合、ローカルに関連するスコープゾーンのリストを構築、およびNot-内部のメッセージのためにゾーンアナウンスメッセージをリッスンするために[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].
（MAAS含む）エンティティは、任意のそのような情報を欠いているだけ[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」ビットを使用しなければなりません。ビットがゼロの場合でもrelative-アドレスを使用するクライアントは、まだMAASからそれらを要求することにより、範囲を得ることができるように、MAASはまだ範囲情報を格納する必要があります。
An internal entity (e.g., an MAAS) should assume that X nests within Y if:
内部エンティティ（例えば、MAAS）があればY内のそのX巣を想定すべきです。
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]秒間その「しないY内部X」を示す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]メッセージの同期を避けるために、各時間の+/- 30％であるため、各スコープゾーンのゾーンアナウンスメッセージを送信するべきです。
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は、それが境界である任意のスコープ内にネストしないことを知っていることを示しています。エントリのタイマーが期限切れになった場合（Xのためのより多くのZAMSが[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.
ZAMスコープゾーンIDがZBR自身のスコープゾーンIDと一致した場合a）には、リーキースコープの設定ミスを知らせます。
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.
原点に向かう次ホップインターフェイス（マルチキャストRIBに従う）はスコープ範囲外である場合、A）は、非凸問題を知らせます。
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スコープゾーンIDが一致しない場合はローカルZBRによって保たれており、この不一致が引き続き発生する、ことが可能リーキースコープの警告を知らせます。
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は（原点ゾーンIDと最初のマルチキャストアドレスによって識別されるように）最後[ZAM-DUP-TIME]秒で受信された場合、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を追加します。 null以外のパスリストでZAMを受けZBRは転送してはならないことZAMバックパスリストに含まれているローカルスコープゾーンに。パスリストは{（E、1）、（A、2を有しているので、例えば、パケット損失に起因介しZAMを取得していない図2、ルータFで、Bからバックゾーン2にZAMを転送しないであろう）、（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のZAMを再発信する各インターフェイス（これは、それを受信した上インターフェイスから返送されていない、またそれは、そのID知られており、表示されている任意のローカルスコープゾーンに送り込まれることを除いパスリストで）。各そのようZAMが由来再ではIDが不明な場合は、ZBRは独自のパスリストにIPアドレスだけでなく、ZAMが送信されているにローカルスコープゾーンのゾーン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爆縮を回避するために、ZLEsはランダム遅延とマルチキャスト及び他のZLEsによって抑制されます。それは以前に任意の宛先へZLEを送っているので、少なくとも[ZLE-MIN-INTERVAL]秒が経過した場合にのみ予定されています。 ZLEをスケジュールするために、ルータは、区間[ZLE抑圧INTERVAL]内のランダム遅延タイマを設定し、他のZLEs用含ま範囲[MZAP相対-GROUP]を聴取します。ランダム遅延タイマーが満了する前には、受信された場合、タイマーはクリアされ、ZLEは送信されません。タイマーが期限切れになった場合、ルータは指示された範囲内で、[MZAP相対-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)
一様ランダムな間隔からランダム値Xを選択[0：1]うC = 256セットT = [ZLE抑圧INTERVAL]ログ（C * X + 1）/ログ（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に近いが応答することを保証し、指数ランダムな分布でこの式は結果。 ZBRsの数が増加したとして純粋に均一な分布を使用すると、スケーリングの問題を発揮し始めます。重複ZLEが選ばれた時間の前に到着した場合ZLEsのみが抑制されているので、両方の余分な帯域幅を消費し、メッセージを送信しますそれらの間の伝搬遅延よりも少ない量で異なる遅延を選ぶつのルータ。したがって、選択された最小の遅延に近い遅延を選択するルータの数を最小限にすることが望ましい、と指数分布は、この目的に適しています。
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.
ルータが送信される予定の重複ZLEメッセージを持っている場合（1）、それはそうもう一つは送信されません独自のメッセージをスケジュールを解除します。
(2) If the ZLE contains the router's own address in the Origin field, it signals a leaky scope misconfiguration.
ZLEが起源フィールドにルータ自身のアドレスが含まれている場合（2）、それは漏れやすいスコープの設定ミスを知らせます。
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]メッセージの同期を避けるために、各時間の+/- 30％であるため、各スコープゾーンのゾーンコンベクシティメッセージ（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.
ZCMsはスコープ範囲自体の[ZCM相対-GROUP]に送られます。これらは、彼らが単にスコープゾーン自体を横切ってマルチキャストされ、ローカルスコープのパケットではなく、必要とする（たとえば、スコープの範囲は、これらのメッセージは239.1.0.252に送信されるべきである。239.1.0.255に239.1.0.0である場合）構築するパスなく、また中間ローカルスコープZBRsによって特別な処理なし。
When a ZCM is received for a given scope X, on an interface which is inside the scope, it follows the rules below:
ZCMが与えスコープXのために受信されると、スコープ内にあるインターフェース上で、それは以下のルールに従います。
(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アドレスに更新されます。新しいエントリは、ゾーンIDは、スコープの任意の活性ZBRの最下位アドレスに収束するように、さらなるメッセージが、そのZBRから受信されない場合[ZCM-HOLDTIME]の後にタイムアウトするようにスケジュールされています。
(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が[ZCM-HOLDTIME]秒間そのZBRから受信されない場合、図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のために、ルータはツァムスを受信したとき、それが作成した各「X内部のない」エントリのためではない - インサイドメッセージ（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は「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.
NIMは、XまたはYのいずれかのための境界とのインターフェイスで受信された場合（1）、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.
NIMは、（マルチキャストRIBによる）メッセージの発信元に向けインターフェイスで受信されなかった場合（2）ZAMS異なり、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]：ZAMSが送信されたローカルスコープで周知基。すべてのマルチキャストアドレス割り当てサーバとゾーン境界ルータはこのグループに耳を傾けます。値：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相対-GROUP]：ZCMsが送信される各スコープゾーンで相対基、。ゾーン境界ルータは、境界された各範囲における相対グループを聴取します。値：（スコープの範囲内の最後の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]：同じスコープのZAMSが転送されない、その間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抑圧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と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.
NIMの場合には、認証されていないメッセージを受け入れることは、ネスト関係の偽の取り消しを引き起こす可能性があります。これは、平坦化ゾーンの階層のセクションを引き起こします。このような平坦化は、階層によってもたらされる効率の利益を減らすだろうが、それが使用できなくなる可能性がありません。
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メッセージを受け入れ、しかし、アプリケーションはそれがないときにスコープゾーンが存在していることを信じるようになる可能性があります。これらが信じられていた場合、そのアプリケーションは、その用途のために、この存在しない管理スコープを使用することもできます。このようなアプリケーションは、正常に通信することができるだろうが、そのトラフィックはさらに、彼らは予想以上に旅行することができることに気づかないだろう。その結果、認証されていないZAMSを受け入れる任意のアプリケーションは、あくまでも目安としてスコープ名を取る必要があり、かつ非ローカルスコープゾーンに送られ、そのトラフィックはどこにでも移動する可能性があることを前提とすべきです。そのようなトラフィックの機密性は、それが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:
また、ツァムスは、ユーザーに割り当てられているユーザに提示し、間違ったアドレスにされている偽の名前をもたらす可能性が名前とスコープのアドレス範囲、および受け入れて認証されていないZAMSのマルチキャストアドレス割り当てサーバ（Maass第）を通知するために使用されています。次のようにこれに対抗するには、MAASのはZAMSを認証します：
(1) A ZBR signs all ZAMs it originates (using an AH).
（1）ZBR記号（AHを使用して）、それが由来する全ZAMS。
(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）A ZBRは、それが以前の送信者を認証することができる場合にのみ中継ZAMに署名します。 ZBRは依然として前方未認証ZAMS（リーク検出を提供するために）必要がありますが、認証されていないものが最後[ZAM-DUP-TIME]秒で受信された場合でも、認証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）A MAASは、それが存在するローカルゾーンの公開鍵を用いて構成されるべきです。このように構成MAASは同じスコープの認証さ一方が受信された場合、認証されていないZAMを無視するべきであり、すべての認証されていないZAMSを無視してもよいです。
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展開ワーキンググループの製品です。マルチキャストアドレスの割り当て作業部会はまた、アプリケーションとスコープ名との相互作用に関する有用なフィードバックを提供します。
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[1]マイヤー、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", Work in Progress.
[3]ターラー、D.、ハンドリー、M.とD. Estrin、 "インターネットマルチキャストアドレス配分アーキテクチャ" が進行中で働いて。
[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]フェナー、W.とS. Casner、 "IPマルチキャストのための`のtraceroute」施設" が進行中で働いています。
[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.、ACM SIGCOMM 98、1998年9月、バンクーバー、カナダの "前方誤り訂正（SHARQFEC）とのハイブリッド自動再送要求をスコープ"。
[9] Hanna, S., Patel, B., and M. Shah. "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[9]ハンナ、S.、パテル、B.、およびM.シャー。 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、1999年12月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[11] IANA, "Address Family Numbers", http://www.isi.edu/in-notes/iana/assignments/address-family-numbers
[11] IANA、 "アドレスファミリ番号"、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]ケント、S.とR.アトキンソン、 "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でのマーク・ハンドリーAT＆Tインターネット研究センターセンター聖、スイート600バークレー、CA 94704 USA
EMail: mjh@aciri.org
メールアドレス：mjh@aciri.org
David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
デビッド・ターラーマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: dthaler@microsoft.com
メールアドレス：dthaler@microsoft.com
Roger Kermode Motorola Australian Research Centre 12 Lord St, Botany, NSW 2019 Australia
ロジャーKermodeモトローラオーストラリアの研究センター12主の聖、植物学、NSW 2019オーストラリア
EMail: Roger.Kermode@motorola.com
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。