RFC2776 日本語訳
2776 Multicast-Scope Zone Announcement Protocol (MZAP). M. Handley, D.Thaler, R. Kermode. February 2000. (Format: TXT=61628 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Handley
Request for Comments: 2776 ACIRI
Category: Standards Track D. Thaler
Microsoft
R. Kermode
Motorola
February 2000
コメントを求めるワーキンググループM.ハンドレー要求をネットワークでつないでください: 2776年のACIRIカテゴリ: 標準化過程D.ターレルマイクロソフトR.カーモードモトローラ2000年2月
Multicast-Scope Zone Announcement Protocol (MZAP)
マルチキャスト範囲ゾーン発表プロトコル(MZAP)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
このドキュメントはプロトコルを定義します、Multicast-範囲Zone Announcementプロトコル(MZAP)、特定の位置で関連しているマルチキャスト管理範囲ゾーンを発見するために。 また、MZAPは管理範囲ゾーンの一般的なmisconfigurationsを発見できるメカニズムを提供します。
Table of Contents
目次
1 Introduction ................................................ 2 2 Terminology ................................................. 4 3 Overview .................................................... 5 3.1 Scope Nesting ............................................. 6 3.2 Other Messages ............................................ 7 3.3 Zone IDs .................................................. 7 4 Detecting Router Misconfigurations .......................... 8 4.1 Detecting non-convex scope zones .......................... 8 4.2 Detecting leaky boundaries for non-local scopes ........... 9 4.3 Detecting a leaky Local Scope zone ........................ 10 4.4 Detecting conflicting scope zones ......................... 10 5 Packet Formats .............................................. 11 5.1 Zone Announcement Message ................................. 14 5.2 Zone Limit Exceeded (ZLE) ................................. 15 5.3 Zone Convexity Message .................................... 15
1つの序論… 2 2用語… 4 3概観… 5 3.1 範囲巣篭もり… 6 他の3.2のメッセージ… 7 3.3 ゾーンID… 7 4検出ルータMisconfigurations… 8 4.1 非凸状な範囲ゾーンを検出します… 8 4.2 非地方の範囲に漏れやすい境界を検出します… 9 4.3 漏れやすいLocal Scopeゾーンを検出します… 10 4.4 闘争している範囲ゾーンを検出します… 10 5 パケット形式… 11 5.1ゾーン発表メッセージ… 14 5.2ゾーンの限界は(ZLE)を超えていました… 15 5.3ゾーン凸状メッセージ… 15
Handley, et al. Standards Track [Page 1] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[1ページ]。
5.4 Not-Inside Message ........................................ 16 6 Message Processing Rules .................................... 17 6.1 Internal entities listening to MZAP messages .............. 17 6.2 Sending ZAMs .............................................. 18 6.3 Receiving ZAMs ............................................ 18 6.4 Sending ZLEs .............................................. 20 6.5 Receiving ZLEs ............................................ 20 6.6 Sending ZCMs .............................................. 21 6.7 Receiving ZCMs ............................................ 21 6.8 Sending NIMs .............................................. 21 6.9 Receiving NIMs ............................................ 22 7 Constants ................................................... 22 8 Security Considerations ..................................... 23 9 Acknowledgements ............................................ 24 10 References ................................................. 25 11 Authors' Addresses ......................................... 26 12 Full Copyright Statement ................................... 27
5.4内部でないことのメッセージ… 16 6 メッセージ処理は統治されます… 17 6.1 MZAPメッセージの内部の実体聴取… 17 6.2 ZAMsを送ります… 18 6.3 ZAMsを受けます… 18 6.4 ZLEsを送ります… 20 6.5 ZLEsを受けます… 20 6.6 ZCMsを送ります… 21 6.7 ZCMsを受けます… 21 6.8 NIMsを送ります… 21 6.9 NIMsを受けます… 22 7つの定数… 22 8 セキュリティ問題… 23 9つの承認… 24 10の参照箇所… 25 11人の作者のアドレス… 26 12の完全な著作権宣言文… 27
1. Introduction
1. 序論
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.
行政上見られたIPマルチキャストのRFC2365[1]で定義される使用が、パケットが特定の範囲のマルチキャストアドレスに記述されるのを許容する、(例えば、239.0、.0、.0、239.255 .255 IPv4) パケットが交差しないようなもののための.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インタフェースあたり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
与えられた範囲への境界の中にあるネットワーク形態の特定の領域は「マルチキャスト範囲ゾーン」として知られています。 同じ範囲を再利用できるので、ネットワークの領域が中でばらばらになって、どんな与えられたマルチキャスト範囲への多くの「マルチキャスト範囲ゾーン」もあるかもしれません。 A
Handley, et al. Standards Track [Page 2] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[2ページ]。
scope zone may have zero or more textual names (in different languages) for the scope, for human convenience. For example, if the range 239.192/14 were assigned to span an entire corporate network, it might be given (internally) the name "BigCo Private Scope".
範囲ゾーンには、ゼロか、より原文の名前が範囲、人間の便宜のためにあるかもしれません(異なった言語で)。 例えば、全体の企業ネットワークにかかるために範囲239.192/14を割り当てるなら、名前「BigCoの個人的な範囲」をそれに与えるでしょうに(内部的に)。
Administrative scope zones may be of any size, and a particular host may be within many administrative scope zones (for different scopes, i.e., for non-overlapping ranges of addresses) of various sizes, as long as scope zones that intersect topologically do not intersect in address range.
管理範囲ゾーンはどんなサイズのものであるかもしれません、そして、特定のホストは様々なサイズの多くの管理範囲ゾーン(すなわち、異なった範囲、非重なっている範囲のアドレスのための)の中にいるかもしれません、横切られる範囲ゾーンがアドレスの範囲で位相的に横切られない限り。
Applications and services are interested in various aspects of the scopes within which they reside:
アプリケーションとサービスはそれらが住んでいる範囲の種々相に興味を持っています:
o Applications which present users with a choice of which scope in
which to operate (e.g., when creating a new session, whether it is
to be confined to a corporate intranet, or whether it should go
out over the public Internet) are interested in the textual names
which have significance to users.
o 作動する(例えば、それが狭いことになっているか否かに関係なく、企業イントラネットかそれとも公共のインターネットの上で出かけるべきであるかどうかに新しいセッションを作成するとき)どの範囲の選択をユーザに与えるアプリケーションがユーザに意味を持っている原文の名前に興味を持っています。
o Services which use "relative" multicast addresses (as defined in
[1]) in every scope are interested in the range of addresses used
by each scope, so that they can apply a constant offset and
compute which address to use in each scope.
o どれが「親類」にマルチキャストアドレスを使用するか。サービス、([1])で定義されるように、各範囲での使用へのどのアドレスが、あらゆる範囲では、一定のオフセットを適用できるように各範囲によって使用されるアドレスの範囲に興味を持っていて、計算されているか。
o Address allocators are interested in the address range, and
whether they are allowed to allocate addresses within the entire
range or not.
o アドレスアロケータはアドレスの範囲に興味を持っていて、それらが全体の範囲の中にアドレスを割り当てることができるかどうかをそうされます。
o Some applications and services may also be interested in the
nesting relationships among scopes. For example, knowledge of the
nesting relationships can be used to perform "expanding-scope"
searches in a similar, but better behaved, manner to the well-
known expanding ring search where the TTL of a query is steadily
increased until a replier can be found. Studies have also shown
that nested scopes can be useful in localizing multicast repair
traffic [8].
o また、いくつかのアプリケーションとサービスが範囲の中の巣篭もり関係に興味を持つかもしれません。 例えば、よく知られている拡張リング検索への質問のTTLが「再-プライヤー」を見つけることができるまで着実に増加する同様の、しかし、よりよく振る舞っている方法で「拡張範囲」検索を実行するのに巣篭もり関係に関する知識を使用できます。 また、研究は、入れ子にされた範囲がマルチキャスト修理交通[8]を局部にとどめる際に役に立つ場合があるのを示しました。
Two barriers currently make administrative scoping difficult to deploy and use:
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 アプリケーションには、ダイナミックにそれらに関連している範囲の情報を発見する方法が全くありません。 これは、管理範囲ゾーンを使用するのを難しくして、したがって、それらを配備する誘因を減少させます。
Handley, et al. Standards Track [Page 3] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[3ページ]。
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 Misconfigurationは簡単です。 凸状に(ゾーンの中の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個のバリアがこのドキュメントによって記述されます。 特に、このドキュメントは実体が、それがどんな範囲ゾーンであるかを学ぶことができるMulticast Scope Zone Announcementプロトコル(MZAP)を定義します。 通常、サーバはMZAPから学習された情報をキャッシュするでしょう、そして、次に、他の手段を使用することで直ちに要求のアプリケーションにこの情報を提供できます、例えば、MADCAP[9]を通して。 また、MZAPはmisconfigured範囲ゾーンが検出されるのを可能にする境界ルータ自体に診断情報を提供します。
2. Terminology
2. 用語
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:
「地方の範囲」がRFC2365[1]で定義されて、リンク地方であるより大きい最も小さい管理範囲を表して、関連アドレスの範囲が239.255と定義される、.0、.0、239.255 .255 .255 包括的です(FF03: : IPv4、IPv6のための/16のための)。 RFC2365は指定します:
"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 Local Scopeになるように定義される、」 Local Scopeは最小量の同封範囲であり、したがって、さらに分割可能ではありません。 Local Scopeの正確な範囲はサイトですが、依存して、局所的に見られた領域はある位相的な規制に従わなければなりません。 特に、Local Scopeはいかなる他の範囲境界にもかかってはいけません。 さらに、Local Scopeはどんなより大きい範囲とも完全に含まれているか、または等しくなければなりません。 範囲の地域が領域に重なる場合、オーバラップの領域がそれ自身のLocal Scopeにあるに違いありません。 「これは、また、どんな範囲境界もLocal Scopeのための境界であることを含意します。」
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.
マルチキャスト範囲Zone Boundary Router(ZBR)は境界によってインタフェースの1つ以上の特定のマルチキャスト範囲に構成されるルータです。 また、境界によってどんな管理範囲ゾーンにも構成されるどんなインタフェースもLocal Scopeゾーンへの境界を持たなければなりません、上で説明されるように。
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.
そのようなルータSHOULD、範囲ゾーンの中にルータ自体があるように、構成されてください。 これは図1(a)に示されます。そこでは、ルータAは、範囲ゾーンの中にあって、境界構成を持っています。
Handley, et al. Standards Track [Page 4] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[4ページ]。
............ ................
. . +B+--> . *B+-->
. . / . / .
. * . + .
. <---+A*---+C+-> . <---+A+---*C+->
. + . . + .
. / . . / .
. zone X <-- . . zone X <-- .
.............. ..................
............ ................ . . . + + B+-->*B+-->//*<。---+ *---+ C+-><。---+ +---*C+->+ + //ゾーンX<--. . X<を区分してください--. … ..................
A,B,C - routers * - boundary interface + - interface
A、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.
範囲ゾーンの外の最初のルータが境界によって構成されるのは、可能です、ルータBとCには、Aが持ちませんが、ゾーンの外にあって、境界構成がありますが、これがNOT RECOMMENDEDである図1(b)で例証されるように。 この規則は、Local Scope境界に申し込みませんが、他のすべての境界ルータに申し込みます。
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アドレスをその範囲ゾーンに意味するために「Zone ID」という用語を定義します。 このIPアドレスの組み合わせと範囲の範囲における最初のマルチキャストアドレスは、唯一範囲ゾーンを特定するのに役立ちます。 各ZBRは他のZBRsからのメッセージの同じ境界に聞こうとして、見られたソースアドレスに基づくZone IDを決定できます。 ZBRsが上下に来るのに応じて、Zone 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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
Constants used by this protocol are shown as [NAME-OF-CONSTANT], and summarized in section 7.
このプロトコルによって使用される定数は、[NAME-OF-CONSTANT]として示されて、セクション7でまとめられます。
3. Overview
3. 概観
When a ZBR is configured correctly, it can deduce which side of the boundary is inside the scope zone and which side is outside it.
ZBRが正しく構成されるとき、境界の側がある範囲が区分するものを推論できます、そして、それの外にどれに面があるかがあります。
Such a ZBR then sends periodic Zone Announcement Messages (ZAMs) for each zone for which it is configured as a boundary into that scope zone, containing information on the scope zone's address range, Zone ID, and textual names. These messages are multicast to the well-
そしてそのようなZBRはそれが境界としてその範囲ゾーンに構成される各ゾーンに周期的なZone Announcement Messages(ZAMs)を送ります、範囲ゾーンのアドレスの範囲、Zone ID、および原文の名前の情報を含んでいて。 これらのメッセージは井戸へのマルチキャストです。
Handley, et al. Standards Track [Page 5] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[5ページ]。
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.
Local Scopeでアドレス[MZAP-LOCAL-GROUP]を知って、Local Scope境界の向こう側に図2に示されるようにZAMメッセージによって示された範囲ゾーンの中のすべてのLocal Scopeゾーンにリレーされます。
###########################
# Zone1 = Zone2 # ##### = large scope zone boundary
*E-----+--->A*-----+-x #
# | = v # ===== = Local Scope boundaries
# | ======*===*==#
# | = B F # ----> = path of ZAM originated by E
G*<-----+--->C*-> | ^ #
# v = <-+---+ # ABCDE = ZBRs
# D = Zone3 #
#######*################### * = boundary interface
########################### # Zone1は大きい範囲Zone2######=ゾーン境界*Eと等しいです。-----+--->は*です。-----+x##| = #に対して===== = ローカルのScope境界#| ======*===*==# # | = B F#---->= E G*<によって溯源されたZAMの経路-----+--->C*->。| ^ # #=<-+に対して---Zone3########*##################+ #ABCDE=ZBRs#D=#、は*境界インタフェースと等しいです。
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.
どんな実体も、その結果、ただ一つの周知のグループアドレスで聴いて、それが住んでいるすべての範囲に関して学ぶことができます。
3.1. Scope Nesting
3.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は範囲ゾーンの間の巣篭もり関係を発見する能力を提供します。 1つがもう片方におけるルータの部分集合から成るなら、2つのゾーンが入れ子にされます、図3に示されるように。
+-----------+ +-----------+ +-------------+
| Zone 1 | | Zone 3 | | Zone 5 |
| +------+| | +------+ | .........|..
| |Zone 2|| | |Zone 4| | : Zone 6 | :
| +--A---+| | C | | D | :
+-----------+ +----+--B---+ +--------E----+ :
:..........:
+-----------+ +-----------+ +-------------+ | ゾーン1| | ゾーン3| | ゾーン5| | +------+| | +------+ | .........|.. | |ゾーン2|| | |ゾーン4| | : ゾーン6| : | +--A---+| | C| | D| : +-----------+ +----+--B---+ +--------E----+ : :..........:
(a) "Contained" (b) "Common Border" (c) "Overlap"
Zone 2 nests Zone 4 nests Zones 5 and 6
inside Zone 1 inside Zone 3 do not nest
(a) 「含まれた」(b)「一般的な境界」(c)「オーバラップ」Zone2は巣ではなく、Zone3の中のZone1の中のZones5と6がするZone4巣を入れ子にします。
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は、1つのゾーンが別のものの中で入れ子にされるかどうか独自に決定できません。 しかしながら、それは、1つのゾーンが別のものの中でどんな巣もしないことを決定できます。 例えば図3で:
o ZBR A will pass ZAMs for zone 1 but will prevent ZAMs from zone 2
from leaving zone 2. When ZBR A first receives a ZAM for zone 1,
it then knows that zone 1 does not nest within zone 2, but it
cannot, however, determine whether zone 2 nests within zone 1.
o ZBR Aは、ゾーン1にZAMsを渡しますが、ゾーン2からのZAMsがゾーン2を出るのを防ぐでしょう。 ZBR Aが最初にゾーン1にZAMを受けると、ゾーン1がゾーン2の中でどんな巣もしないのを知っていますが、しかしながら、それは、ゾーン2がゾーン1の中で巣ごもるかどうか決定できません。
Handley, et al. Standards Track [Page 6] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[6ページ]。
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として機能して、したがって、1がもう片方で入れ子にされるかどうか決定できません。 しかしながら、ZBR Cは、ゾーン3にZAMを受けるとき、ゾーン3がゾーン4の中でどんな巣もしないことを決定できます、それがゾーン3ではなく、ゾーン4への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として5ではなくゾーン6を機能させるだけです、したがって、ZBR Dはゾーン5がゾーン5にZAMを聞くところのゾーン6の中でどんな巣もしないと推論できます。 同様に、ZBR EはZBRとして6ではなくゾーン5を機能させるだけです、したがって、ZBR Eはゾーン6がゾーン6にZAMを聞くところのゾーン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.Suchメッセージが送られるゾーンの中のそうでないという事実を周知の[MZAP-LOCAL-GROUP]に言い表して、同じ実体によってこのようにして見られるNot-内部のMessages(NIMs)にZAMメッセージ(例えば、MADCAPサーバ)を聞かせることによって、これをします。 そして、そのような実体は、2の間の巣篭もり関係がどんな反対の証拠の持続している欠如に基づいて見られることを決定できます。
3.2. Other Messages
3.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.
タイプ(Zone Convexity Messages(ZCMs)とZone Limit Exceeded(ZLE)メッセージ)が、ルータだけによって使用されて、彼らが一貫性のためにそれらの構成を比較して、misconfigurationsを検出するのを可能にするという他の2メッセージ。 これらのメッセージは、それらが参照する範囲ゾーンに関連している範囲の範囲の中のMZAPの相対アドレスに送られて、したがって、ルータ以外の実体によって通常見られません。 特定のmisconfigurationシナリオを検出することにおける彼らの使用は次のセクションでカバーされているでしょう。
Packet formats for all messages are described in Section 5.
すべてのメッセージのためのパケット・フォーマットはセクション5で説明されます。
3.3. Zone IDs
3.3. ゾーンID
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アドレスを使用します、そのゾーンへのZone IDとして。 そして、それは将来送られるべきZCM(そして、ZAM)メッセージの計画をします(それはすぐに、それらを送りません)。 与えられた範囲にZCMを受け取るとき、その範囲のためにZBRs(それ自体を含んでいる)のローカルのリストに送付者を追加します、そして、リストで最も低いIPアドレスになるようにZone IDをアップデートします。 そのZBRからさらなるメッセージを全く受け取らないなら、結局リストにおけるエントリーを調節します、Zone IDが範囲へのどんなアクティブなZBRの最も低いアドレスにも一点に集まるように。
Handley, et al. Standards Track [Page 7] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[7ページ]。
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で説明された漏れやすいLocal範囲を検出すると2が当てにされるので手順が異なったZone IDを持っている同じ範囲の範囲へのゾーンをばらばらにならせるからです。 ZAMsがZone IDを計算するのに使用されると、Local Scope境界の向こう側に漏れるZAMsが2つのゾーンを同じZone IDに一点に集めさせるでしょう。
4. Detecting Router Misconfigurations
4. ルータMisconfigurationsを検出します。
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.
このセクションでは、私たちはどう様々なエラー条件を検出するかを覆います。 何か誤りが検出されるなら、ルータは、misconfigurationの自然にネットワーク管理者の注意を喚起するのを試みるべきです。 MZAPの範囲の外にこれをする手段があります。
4.1. Detecting non-convex scope zones
4.1. 非凸状な範囲ゾーンを検出します。
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.
ゾーンConvexity Messages(ZCMs)はルータによって使用されます。(非凸状な管理範囲ゾーンを検出して、ゾーンは1可能なmisconfigurationです)。 受信機以来ゾーンがアプリケーションのために問題を引き起こす場合がある非凸の範囲は同じ範囲ゾーンの中の送付者から行政上見られたパケットを決して見ないかもしれません、それらの間を移動するパケットが境界で落とされるかもしれないので。
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を通した)の外に行きます。 ここで、Router BとRouter Cは与えられた範囲ゾーンの中の彼らがそれぞれ各報告がある境界を持っているZCMsにそれらが連絡をいただいたゾーンの他の境界ルータを送ります。 Router Dは図4の、Routerビーズメッセージを見ることができません、CのBのレポートを見ることができるのでゾーンが凸状でないと結論づけることができるのを除いて。
#####*####========
# B # = ##### = non-convex scope boundary
# |->A* =
# | # = ===== = other scope boundaries
# | ####*####
# | E # ----> = path of B's ZCM
# v D*
# C # * = boundary interface
#####*############
#####*####======== # B#=#####、は非凸状な範囲境界#と等しいです。|->は*=#です。| # = ===== = 他の範囲境界#| ####*#### # | E#---->= ビーズZCM#対D*#C#*=境界インタフェース#####*############の経路
Figure 4: Non-convexity detection
図4: 非凸状検出
Handley, et al. Standards Track [Page 8] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[8ページ]。
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に向かった次のホップインタフェース(マルチキャスト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
またはZBRが受け取られたZCMsにもかかわらず、どんなZCMにも記載されないなら、(2)は[ZCM-HOLDTIME]秒の間のそのZBRから受け取られています、図4で例証されるように。
(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) また、上に、以下の通り(1)のZCMsに、それと同様の方法でZAMメッセージを使用できます: ZBRからZAMを受け取るなら、与えられた範囲ゾーンの中のインタフェース、およびそのZBRに向かった次のホップインタフェース(マルチキャストRIBによると)に、範囲ゾーンが外にあります。
Zone Convexity Messages MAY also be sent and received by correctly configured ordinary hosts within a scope region, which may be a useful diagnostic facility that does not require privileged access.
また、ゾーンConvexity Messagesは範囲の地域の中に正しく構成された普通のホストによって、送られて、受け取られるかもしれません。地域は特権的アクセスを必要としない役に立つ診断施設であるかもしれません。
4.2. Detecting leaky boundaries for non-local scopes
4.2. 非地方の範囲に漏れやすい境界を検出します。
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.
「漏れやすい」境界は存在するべきであるところでインタフェースで境界を適用しない何らかのルータのため「穴」が論理的にあるものです。 したがって、外で見られたデータ漏出をもたらして、境界は完全にネットワークの1つの断片を囲むというわけではありません。
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) インタフェースの範囲境界の中で由来する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
=============##############
=============#####*######## = Zone1#A Zone2#C=はルータ=+をmisconfiguredしました。---->*E対#=| # B######、は漏れやすい範囲境界と等しいです。=======*=====#====*=======# = D#| # ===== = 他の範囲境界は^と等しいです。-----*C<--+ #=Zone4#Zone3#---->= ZAMsの経路=============##############
Figure 5: ZAM Leaking
図5: ZAM漏出
Handley, et al. Standards Track [Page 9] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[9ページ]。
(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) Zone Length Exceeded(ZLE)メッセージが受信されているなら。 また、ZAMパケットはZones Traveled Limitを含んでいます。 ゾーンが横断したLocal Scopeの数がZones Traveled Limitと等しくなるなら、ZLEメッセージは発生します(内部破裂を防ぐための抑圧メカニズムは後でProcessing Rules部で説明されます)。 ZLEsはパケットが同じ範囲ゾーンの別の部分に戻らないところに漏出を検出しますが、代わりにZAM創始者からほど遠い他のLocal Scopeゾーンに達します。
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).
どちらかの場合では、misconfiguredルータは、メッセージの起源か受け取られたメッセージ(または、恐らくZBR自身であるそのような2ZBRsの間の経路のルータ)に含まれているZBR経路リストのルータの1つのどちらかになるでしょう。
4.3. Detecting a leaky Local Scope zone
4.3. 漏れやすいLocal Scopeゾーンを検出します。
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:
地方の範囲は、ルータがいくつかのインタフェースに管理範囲境界を持っているなら漏れやすいのですが、RFC2365の指定されるとしてのそのインタフェースにLocal Scope境界を持っていません。 以下の方法でこれを検出できます:
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のScope Zone IDをそれ自身のZone IDと比較します。 2が合っていないなら、これはmisconfigurationに関する証拠です。 一時的なミスマッチが最も低く記述されたZBRの可到達性における最近の変化直後結果として生じるかもしれないので、ミスマッチがしつこい場合にだけ、misconfigurationは想定されるべきです。
The exact location of the problem can be found by doing an mtrace [5] from the router detecting the problem, back to the ZAM origin, for any group within the address range identified by the ZAM. The router at fault will be the one reporting that a boundary was reached.
問題を検出しながらルータからmtrace[5]をすることによって、問題の正確な位置を見つけることができます、ZAMの起源に、ZAMによって特定されたアドレスの範囲の中のどんなグループのためにも。 ルータ誤るのは、境界に達したと報告するものでしょう。
4.4. Detecting conflicting scope zones
4.4. 闘争している範囲ゾーンを検出します。
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を受けますが、範囲名が合っていないなら。
Handley, et al. Standards Track [Page 10] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[10ページ]。
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.
どちらかのタイプの上の闘争を検出するのは、メッセージを溯源するローカルルータかルータのどちらかがmisconfiguredされるのを示します。 SHOULDが剥取る構成ツールは、偶然のmisconfigurationを避けるためにそれぞれの名前の首尾からスペースを空白にします。
5. Packet Formats
5. パケット・フォーマット
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の上に送ります、255の[MZAP-PORT]の仕向港とIPv4 TTLかIPv6 Hop Limitと共に。
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 MUSTについて言及させるときには、メッセージが参照される範囲ゾーンの中のいたる所に意味を持っているソースアドレスを使用してください。 例えば、リンクローカルのアドレスを使用してはいけません。
The common MZAP message header (which follows the UDP header), is shown below:
一般的なMZAPメッセージヘッダー(UDPヘッダーに続く)は示された下です:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |B| PTYPE |Address Family | NameCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Origin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone End Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Zone Name-1 (variable length) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | Encoded Zone Name-N (variable length) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン|B| PTYPE|アドレス家族| NameCount| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージの起源| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゾーンIDアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゾーン開始アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゾーン終わりのアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード化されたZone Name-1(可変長)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | コード化されたZone Name-N(可変長)| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 詰め物(必要であるなら)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
The version defined in this document is version 0.
バージョン: 本書では定義されたバージョンはバージョン0です。
Handley, et al. Standards Track [Page 11] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[11ページ]。
"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)、これは範囲ゾーン境界への開始アドレスを与えます。 次に、.255、Zone Start Addressはそうです。例えば、ゾーンであるなら239.1のための境界が.0である、.0〜239.1、.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)、これは範囲ゾーン境界への終了アドレスを与えます。 次に、.255、Zone End Addressはそうです。例えば、ゾーンであるなら239.1のための境界が.0である、.0〜239.1、.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アドレスを与えます。 Zone Start AddressとZone End Addressと共に、それは固有のIDをゾーンに形成します。 通常、このIDが起源があるLocal ScopeゾーンのIDと異なっていることに注意してください。
Handley, et al. Standards Track [Page 12] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[12ページ]。
Encoded Zone Name:
+--------------------+
|D| Reserved (7 bits)|
+--------------------+
| LangLen (1 byte) |
+--------------------+-----------+
| Language Tag (variable size) |
+--------------------+-----------+
| NameLen (1 byte) |
+--------------------+-----------+
| Zone Name (variable size) |
+--------------------------------+
コード化されたゾーン名: +--------------------+ |D| 予約されます(7ビット)。| +--------------------+ | LangLen(1バイト)| +--------------------+-----------+ | 言語Tag(可変サイズ)| +--------------------+-----------+ | NameLen(1バイト)| +--------------------+-----------+ | ゾーンName(可変サイズ)| +--------------------------------+
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.
「デフォルトLanguage」(D)ビット: セットして、どんな名前もa必要な言語で利用可能でないなら、使用されていた状態で以下の言語の名前がそうあるべきである優先を示します。
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].
言語タグ: (可変サイズ) ゾーン名の用語を示す「アン米国」などの言語タグ。 言語タグは[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.
ゾーン名: 複数、8ビットでは、Zone Nameは範囲ゾーン(eg: 「ISI西のサイト」)に付与という名前を示しながら[4]をコード化するUTF-8のISO10646文字列です。 それは、比較的短いはずであり、長さは256バイト未満でなければなりません。 余白SHOULDは、偶然の闘争を避けるために始めから剥取られて、コード化の前に名義でそれぞれを終わらせます。
Padding (if needed):
The end of the MZAP header is padded with null bytes until it is
4-byte aligned.
詰め物(必要であるなら): 並べられた状態でそれが4バイトになるまで、MZAPヘッダーの端はヌルバイトで水増しされます。
Handley, et al. Standards Track [Page 13] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[13ページ]。
5.1. Zone Announcement Message
5.1. ゾーン発表メッセージ
A Zone Announcement Message has PTYPE=0, and is periodically sent by a ZBR for each scope for which it is a boundary, EXCEPT:
Zone Announcement MessageはPTYPE=0を持って、以下を除いて、定期的にZBRによってそれが境界である各範囲に送られます。
o the Local Scope
o 地方の範囲
o the Link-local scope
o Link地方の範囲
The format of a Zone Announcement Message is shown below:
Zone Announcement Messageの書式は以下に示されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZT | ZTL | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Zone ID Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++MZAPヘッダー+++++++++++++++++++++++++++++++++| ZT| ZTL| 保持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのゾーンIDアドレス0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのゾーンIDアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータアドレスN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのゾーンIDアドレス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ビットのThisはこのメッセージ経路に保管されていたLocal Zone 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ビットのThisはパケットが横断できるローカルのゾーンの数における限界を与えます。 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]に設定されるべきです。
Handley, et al. Standards Track [Page 14] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[14ページ]。
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が通ったLocal Zone ID Addresses(ローカルのゾーンのZone ID Address)のリストと、パケットを進めたルータのIPアドレスです。 起源ルータは「ZAMを送るとき0インチがさばくローカルのゾーンIDアドレス」に記入します。 Local Scope境界の向こう側にZAMを送るあらゆるLocal Scopeルータが進めた状態でメッセージがそうであるゾーンのパケットがあるローカルのゾーンのLocal Zone ID Addressを加えなければなりません、そして、自分自身のIPはそれに従って、ZTをこのリスト、および増分の終わりまで記述します。 ゾーン経路はZAMが最初に送られるものを空にすることです。
5.2. Zone Limit Exceeded (ZLE)
5.2. 超えられていたゾーンの限界(ZLE)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ZLEの書式は以下に示されます: 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ヘッダー+++++++++++++++++++++++++++++++++| ZT| ZTL| 保持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのゾーンIDアドレス0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのゾーンIDアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータアドレスN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルのゾーンIDアドレスN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All fields are copied from the ZAM, except PTYPE which is set to one.
1つに用意ができているPTYPEを除いて、すべての分野がZAMからコピーされます。
5.3. Zone Convexity Message
5.3. ゾーン凸状メッセージ
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.
Zone Announcement MessageはPTYPE=2を持って、定期的にZBRによってそれが境界(Linkの地方の範囲を除いた)である各範囲に送られます。 ZCMのものがLocal Scopeで送られることに注意してください。
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]に送られるZone Announcement Messagesと異なって、範囲ゾーン自体の[ZCM-RELATIVE-GROUP]にZone Convexity Messagesを送ります。 ZCMの書式は以下に示されます:
Handley, et al. Standards Track [Page 15] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[15ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZNUM | unused | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZBR Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZBR Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++MZAPヘッダー+++++++++++++++++++++++++++++++++| ZNUM| 未使用| 保持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZBRアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ZBRアドレス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)を記述します: Thisがさばく8ビットはこのメッセージに含まれたZBR Addressesの数を与えます。
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アドレス: これらの分野がMessage Origin ZBRがZCMsを受けましたが、保持時間にはだれのものがあるかが期限が切れなかった他のZBRsのアドレスを与える32ビット(IPv4)か128ビット(IPv6)。 ルータはパケットをうまくはめ込むそのようなすべてのアドレスを含むべきです、すべてが合わないならそれが最近含んでいないものを好んで。
5.4. Not-Inside Message
5.4. 内部でないことのメッセージ
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-内部のMessage(NIM)はPTYPE=3を持って、定期的に範囲Xが別の範囲Y(「YでないところのX」)の中でどんな巣もしないのを知っているZBRによって送られます:
The format of a Not-Inside Message is shown below:
Not-内部のMessageの書式は以下に示されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MZAP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Not-Inside Zone Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++MZAPヘッダー+++++++++++++++++++++++++++++++++| 内部でないことのゾーン開始アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Handley, et al. Standards Track [Page 16] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[16ページ]。
The fields are as follows:
分野は以下の通りです:
MZAP Header: Header fields identifying the scope X. The Name Count
may be 0.
MZAPヘッダー: ヘッダーフィールド、範囲X.を特定して、Name Countは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への開始アドレスを与えます。
6. Message Processing Rules
6. メッセージ処理規則
6.1. Internal entities listening to MZAP messages
6.1. MZAPメッセージを聞く内部の実体
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.
どんなホストやアプリケーションも局所的に関連範囲ゾーンのリストを確立するためにZone Announcement Messagesの聞こうとするために[MZAP-LOCAL-GROUP]に加わるかもしれません、そして、Not-内部を、Messagesはそれであるなら情報を入れ子にしながら、学びたがっています。 しかしながら、そのようなメッセージを聞くのは、定期的なアプリケーションがこの情報を発見するお勧めの方法ではありません。 これらのアプリケーションについて、通常、地方のMulticast Address Allocation Server(マース)[3]について質問して、クライアントはMADCAPメッセージで質問できます。(順番に、[3]は、範囲情報を保守するためにZone Announcement MessagesとNot-内部のMessagesを聞きます)。
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].
どんなそのような情報も欠いている実体(マースを含んでいる)は、Global Scope、およびLocal Scopeの中にそれがあると仮定できるだけです。それの両方がLocal Scopeのために[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を受ける内部の実体(例えば、マース)はそれに関連している情報を分析するでしょう、アドレスの範囲や、名前などのように。 また、そのような情報を受け取るアドレスアロケータは、それがそれがアドレスを割り当てるかもしれない範囲のセットにアドレスの範囲を追加できるかどうか(明確に、それはビットがゼロである場合にだけそれらを加えるかもしれません)決定するのに「B」ビットを使用しなければなりません。 ビットがそうであっても、ゼロ、MAAS SHOULDは、親類アドレスを使用するクライアントがマースからそれらを要求することによってまだ範囲を得ることができるように、まだ範囲情報を格納しています。
An internal entity (e.g., an MAAS) should assume that X nests within Y if:
内部の実体(例えば、マース)が、XがYの中で巣ごもると仮定するべきである、:
a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME]
seconds ago, AND
最初に[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が少なくとも[NIM-HOLDTIME]秒の間のその「YでないところのX」を示しているのを聞いていません。
Handley, et al. Standards Track [Page 17] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[17ページ]。
6.2. Sending ZAMs
6.2. 送付ZAMs
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]についてそれぞれの範囲ゾーンへのそれが境界であるZone Announcement Messageにあらゆる[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パケットはZones Traveled Limit(ZTL)を含んでいます。 ZAM経路のLocal Zone IDの数がZones Traveled Limitと等しくなると、パケットは落とされるでしょう。 ZTL分野をパケットが最初に送られて、32をデフォルトとするとき、設定されますが、ネットワーク管理者がゾーンの予想されたサイズを知っているなら、下側の値に設定できます。
6.3. Receiving ZAMs
6.3. ZAMsを受けます。
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がOUTSIDEから範囲(すなわち、境界インタフェースの上で範囲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のScope Zone IDがZBRの自己のScope Zone IDに合っているなら、漏れやすい範囲misconfigurationに合図してください。
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のプレースメントがお勧めの構成でないので、以前に検討したことであるが。
Handley, et al. Standards Track [Page 18] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[18ページ]。
2) If the ZAM originated from INSIDE the scope:
2) ZAMがINSIDEから範囲を溯源したなら:
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) 範囲ゾーンの外にOriginに向かった次のホップインタフェース(マルチキャストRIBによると)があるなら、非凸状な問題に合図してください。
b) If the Origin's Scope Zone ID in the ZAM does not match the
Scope Zone ID kept by the local ZBR, and this mismatch
continues to occur, then signal a possible leaky scope warning.
b) ZAMのOriginのScope Zone IDが地方のZBRによって保たれたScope Zone 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) Local Scope境界でないインタフェースにZAMを受け取って、経路リストにおける最後のLocal Zone ID Addressが0歳であるなら、ZBRはZAMが受け取られたローカルのゾーンのLocal Zone ID Addressに記入します。
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.
そして、同じ範囲(起源Zone IDと最初に、マルチキャストアドレスによって特定されるように)へのZAMが最終で容認された[ZAM-DUP-タイム誌]秒であったなら、ZAMは捨てられます。 さもなければ、ZAMは少なくとも[ZAM-DUP-タイム誌]数秒間、キャッシュされます。 図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.
次に、メッセージにおけるZones Travelledカウントは増加されて、アップデートされたカウントが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が住んでいるLocal ScopeゾーンのZone IDがZAMの経路リストに既にないなら、ZAMはすぐに、Local Scopeゾーンの中で再溯源されます。 それは、それ自身のアドレスとメッセージが転送されているLocal ScopeゾーンのZone IDがそうする前にZAM経路に記載すると言い足します。 非ヌル経路リストでZAMを受けるZBRは経路リストに含まれているLocal ScopeゾーンにそのZAMを送って戻してはいけません。 そして、例えば、図2では、ルータF(パケット損失によるAを通してZAMを手に入れませんでした)が経路リストが送ったのでZAMをBからZone2に送って戻さない、(E、1) (A、2) (B、3)、したがって、Zone2は既に現れます。
In addition, the ZBR re-originates the ZAM out each interface with a Local Scope boundary (except that it is not sent back out the interface over which it was received, nor is it sent into any local scope zone whose ID is known and appears in the path list). In each such ZAM re-originated, the ZBR adds its own IP address to the path
さらに、ZBRはLocal Scope境界との各インタフェースからZAMを再溯源します(それが送られないのを除いて、それが受け取られて、それであるインタフェースからの後部はIDが経路リストに知られていて、現れるどんなローカルの範囲ゾーンにも発信しました)。 そのようなZAMが再溯源したそれぞれでは、ZBRはそれ自身のIPアドレスを経路に加えます。
Handley, et al. Standards Track [Page 19] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[19ページ]。
list, as well as the Zone ID Address of the Local Scope Zone into which the ZAM is being sent, or 0 if the ID is unknown. (For example, if the other end of a point-to-point link also has a boundary on the interface, then the link has no Local Scope Zone ID.)
ZAMが送るか、または0歳であるLocal Scope ZoneのZone ID AddressがIDであるなら未知であるのと同じくらいよく記載してください。 (例えば、また、ポイントツーポイント接続のもう一方の端がインタフェースに境界を持っているなら、リンクには、Local Scope Zone IDが全くありません。)
6.4. Sending ZLEs
6.4. 送付ZLEs
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パケットを進めたならZone Traveled Limitを超えていたローカルのゾーン境界ルータはこのパケットを送ります。 ZLE内部破裂を避けるために、ZLEsは他のZLEsによる無作為の遅れであって抑圧されるのがあるマルチキャストです。 以前にどんな目的地にもZLEを送って以来少なくとも[ZLE- MIN-INTERVAL]秒が経過している場合にだけ、それは予定されています。 ルータは、ZLEの計画をするように、間隔[ZLE-SUPPRESSION-INTERVAL]中に無作為のディレイタイマを設定して、含まれている範囲の中で他のZLEsに関して[MZAP-RELATIVE-GROUP]を聞きます。 無作為のディレイタイマが期限が切れる前にいずれか受け取られているなら、タイマはきれいにされます、そして、ZLEは送られません。 タイマが期限が切れるなら、ルータは示された範囲の中の[MZAP-RELATIVE-GROUP]にZLEを送ります。
The method used to choose a random delay (T) is as follows:
無作為の遅れ(T)を選ぶのに使用される方法は以下の通りです:
Choose a random value X from the uniform random interval [0:1]
Let C = 256
Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)
[0:1]がC=256Set T=[ZLE-SUPPRESSION-INTERVAL]に登録するか(C*X+1)、または登録させる一定の無作為の間隔から無作為の値Xを選んでください。(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.
この方程式はおよそ1ZBRが応じるのを確実にする指数のランダム分布をもたらします。 純粋に一定の分配を使用するのは、ZBRsの数が上昇したとき問題をスケーリングしながら、展示会に出品し始めるでしょう。 写しZLEが選ばれた時の前に到着する場合にだけZLEsが抑圧されるので、量に従ってそれらの間の伝播遅延ほど異ならない遅れを選ぶ2つのルータがともにメッセージを送るでしょう、余分な帯域幅を消費して。 したがって、選ばれる中で最も低い遅れの近くで遅れを選ぶルータの数を最小にするのが望ましく、指数分布はこのために適当です。
A router SHOULD NOT send more than one Zone Limit Exceeded message every [ZLE-MIN-INTERVAL] regardless of destination.
SHOULD NOTが目的地にかかわらず1Zone Limit Exceededのメッセージよりあらゆる[ZLE-MIN-INTERVAL]を送るルータ。
6.5. Receiving ZLEs
6.5. ZLEsを受けます。
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メッセージがルータであるならあって、それはしたがって、別の1つが送られないという非スケジュールのそれ自身のメッセージです。
(2) If the ZLE contains the router's own address in the Origin field,
it signals a leaky scope misconfiguration.
(2) ZLEがOrigin分野にルータの自己のアドレスを保管しているなら、それは漏れやすい範囲misconfigurationに合図します。
Handley, et al. Standards Track [Page 20] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[20ページ]。
6.6. Sending ZCMs
6.6. 送付ZCMs
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]についてそれぞれの範囲ゾーンへのそれが境界であるZone Convexity Message(ZCM)にあらゆる[ZCM-INTERVAL]を秒、+/-30%送るはずです。
ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself. (For example, if the scope range is 239.1.0.0 to 239.1.0.255, then these messages should be sent to 239.1.0.252.) As these are not Locally-Scoped packets, they are simply multicast across the scope zone itself, and require no path to be built up, nor any special processing by intermediate Local Scope ZBRs.
見られた範囲自体の[ZCM-RELATIVE-GROUP]にZCMsを送ります。 .255、次にこれらのメッセージを239.1に送るべきです。(範囲の範囲が例えば239.1である、.0、.0〜239.1、.0、.0 .252、) これらがLocallyによって見られたパケットでないので、単に範囲ゾーン自体中のマルチキャストであり、経路が全く確立されないのが必要です、中間的Local Scope ZBRsによるまたはどんな特別な処理。
6.7. Receiving ZCMs
6.7. ZCMsを受けます。
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(それ自体を含んでいる)のローカルのリストにOriginを追加します、そして、リストで最も低いIPアドレスになるようにZone IDをアップデートします。 そのZBRからさらなるメッセージを全く受け取らないなら、新しいエントリーは[ZCM-HOLDTIME]の後に外で調節する予定です、Zone IDが範囲へのどんなアクティブなZBRの最も低いアドレスにも一点に集まるように。
(2) If a ZBR is listed in ZCMs received, but the next-hop interface
(according to the multicast RIB) towards that ZBR is outside the
scope zone, or if no ZCM is received from that ZBR for [ZCM-
HOLDTIME] seconds, as in the example in Figure 4, then signal a
non-convexity problem.
(2) ZBRが受け取られたZCMsに記載されていますが、範囲ゾーンの外にそのZBRに向かった次のホップインタフェース(マルチキャストRIBによると)があるか、または[ZCM- HOLDTIME]秒の間、図4の例のようにそのZBRからZCMを全く受け取らないなら、非凸状問題に合図してください。
(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のそれぞれの原文の名前に関して、同じ範囲と言語のための名前が局所的に構成されているかどうかを見てください。 そうだとすれば、範囲名だけが合わないで、信号は地元の管理者への範囲名前闘争です。
6.8. Sending NIMs
6.8. 送付NIMs
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に、ルータがそれぞれのために、Not-内部のMessage(NIM)を溯源する、「」 ZAMs同様のa ZAMを受けるときそれが作成していないどんなエントリーの中のX、このメッセージは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]についてそのようなNot-内部のMessageにあらゆる[NIM-INTERVAL]を秒、+/-30%送るはずです。
Handley, et al. Standards Track [Page 21] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[21ページ]。
6.9. Receiving NIMs
6.9. NIMsを受けます。
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) XかYのどちらかのために境界とのインタフェースにNIMを受け取ったなら、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) NIMがインタフェースにメッセージの起源に向かって受け取られなかったなら(Multicast RIBによると)、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-タイム誌]秒であったなら、NIMは進められません。
(4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.
(4) さもなければ、NIMは少なくとも[ZAM-DUP-タイム誌]数秒間、キャッシュされます。
(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のどちらかのために境界とのどんなインタフェースも出しました。
7. Constants
7. 定数
[MZAP-PORT]: The well-known UDP port to which all MZAP messages are sent. Value: 2106.
[MZAP-ポート]: すべての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 Scopeの周知のグループをどのZAMsに送るか。 すべてのMulticast Address AllocationサーバとZone Boundary Routersはこのグループを聞きます。 値: 239.255.255.252、IPv4のために。
[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の相対的なグループ]: それぞれの範囲ゾーンの相対的なグループ。(ZCMsはそれに送られます)。 Zone Boundary Routerはそれが境界である各範囲で相対的なグループを聞きます。 値: (範囲の範囲の最後のIPアドレス) - 3. 例えば、Local Scopeでは、相対的なグループは[MZAP-LOCAL-GROUP]アドレスと同じです。
[ZAM-INTERVAL]: The interval at which a Zone Boundary Router originates Zone Announcement Messages. Default value: 600 seconds (10 minutes).
[ZAM-間隔]: Zone Boundary RouterがZone Announcement Messagesを溯源する間隔。 デフォルト値: 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のインクルードへのholdtime。 このSHOULD、少なくとも3*[ZAM-INTERVAL]に設定されてください。 デフォルト値: 1860秒(31分)。
Handley, et al. Standards Track [Page 22] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[22ページ]。
[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-タイム誌]: 同じ範囲へのZAMsが進められないZAMを進めた後の時間間隔。 デフォルト値: 30秒。
[ZCM-INTERVAL]: The interval at which a Zone Boundary Router originates Zone Convexity Messages. Default value: 600 seconds (10 minutes).
[ZCM-間隔]: Zone Boundary RouterがZone Convexity Messagesを溯源する間隔。 デフォルト値: 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のインクルードへのholdtime。 このSHOULD、少なくとも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抑圧間隔]: ZLEメッセージを送る前に無作為の遅れを選ぶ間隔。 デフォルト値: 300秒(5分)。
[ZLE-MIN-INTERVAL]: The minimum interval between sending ZLE messages, regardless of destination. Default value: 300 seconds (5 minutes).
[ZLE分、間隔、]、: 目的地にかかわらずメッセージをZLEに送るところの最小間隔。 デフォルト値: 300秒(5分)。
[NIM-INTERVAL]: The interval at which a Zone Boundary Router originates Not-Inside Messages. Default value: 1800 seconds (30 minutes).
[NIM-間隔]: Zone Boundary RouterがNot-内部のMessagesを溯源する間隔。 デフォルト値: 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の中に状態を含むholdtime。 このSHOULD、少なくとも3*[NIM-INTERVAL]に設定されてください。 デフォルト値: 5460 (91分)
8. Security Considerations
8. セキュリティ問題
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メッセージの権限のない読書が比較的無毒である間(したがって、一般に、暗号化は問題ではありません)、unauthenticated MZAPメッセージを受け入れるのは問題が多い場合があります。 IPsec Authentication Header(AH)[12]を使用することによって、MZAPメッセージの認証を提供できます。
In the case of ZCMs and ZLEs, an attacker can cause false logging of convexity and leakage problems. It is likely that is would be purely an annoyance, and not cause any significant problem. (Such messages could be authenticated, but since they may be sent within large scopes, the receiver may not be able to authenticate a non-malicious sender.)
ZCMsとZLEsの場合では、攻撃者は凸状と漏出問題の誤った伐採を引き起こす場合があります。それがありそうであり、すなわち、純粋にいらだちであり、少しの重大な問題も引き起こさないでしょう。 (そのようなメッセージを認証できましたが、受信機は大きい範囲の中でそれらを送るかもしれないので、非悪意がある送付者は認証できないかもしれません。)
ZAMs and NIMs, on the other hand, are sent within the Local Scope, where assuming a security relationship between senders and receivers is more practical.
他方では、Local Scopeの中でZAMsとNIMsを送ります。そこでは、セキュリティが送付者と受信機との関係であると仮定するのが、より実用的です。
Handley, et al. Standards Track [Page 23] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[23ページ]。
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.
信じていないとき、しかしながら、unauthenticated ZAMメッセージを受け入れるのに、アプリケーションは、範囲ゾーンが存在すると信じるかもしれません。 これらが信じられていたなら、アプリケーションは、彼らの用途にこの実在しない管理範囲を使用するのを選ぶかもしれません。 そのようなアプリケーションは首尾よく交信できるでしょうが、それらの交通が予想したより遠くに旅行することであるかもしれないことを気づかないでしょう。 その結果、unauthenticated ZAMsを受け入れるどんなアプリケーションもガイドラインとして範囲名をみなすだけでよいです、そして、SHOULDは非ローカルの範囲ゾーンに送られたそれらの交通がどこでも伝わるかもしれないと仮定します。 そのような交通の秘密性は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は範囲の名前とアドレスの範囲についてMulticast Address Allocation Servers(MAASs)に知らせるのに使用されます、そして、unauthenticated ZAMsを受け入れると、ユーザ、およびユーザに割り当てられる間違ったアドレスに提示される偽名はもたらされるかもしれません。 これを打ち返すために、マースのものは以下のZAMsを認証します:
(1) A ZBR signs all ZAMs it originates (using an AH).
(1) ZBRはそれが溯源するすべてのZAMsにサインします(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サインa ZAM、前の送付者を認証できる場合にだけ。 ZBR MUSTはまだ、不-認証されたZAMs(漏水検知を提供する)を進めていますが、不-認証されたものが最終で容認された[ZAM-DUP-タイム誌]秒であったとしても、認証されたZAMを伝播するでしょうに。
(3) A MAAS SHOULD be configured with the public key of the local zone
in which it resides. A MAAS thus configured SHOULD ignore an
unauthenticated ZAM if an authenticated one for the same scope
has been received, and MAY ignore all unauthenticated ZAMs.
(3) MAAS SHOULD、それが住んでいるローカルのゾーンの公開鍵で、構成されてください。 その結果、同じ範囲への認証された受け取られて、すべてのunauthenticated ZAMsを無視するかもしれないなら、マースは、SHOULDがunauthenticated ZAMを無視するのを構成しました。
9. Acknowledgements
9. 承認
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作業部会の製品です、とヴァン・ジェーコブソンがこのプロトコルにつながった着想のいくつかを前提としました。(作業部会のメンバーは多くの役に立つコメントと提案を提供しました)。 また、Multicast Address Allocation作業部会はアプリケーションとの範囲名と相互作用に関する役に立つフィードバックを提供しました。
Handley, et al. Standards Track [Page 24] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[24ページ]。
10. References
10. 参照
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[1] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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、1998年1月のF.、「UTF-8、ISO10646の変化形式」RFC2279。
[5] Fenner, W. and S. Casner, "A `traceroute' facility for IP
Multicast", Work in Progress.
[5] ProgressのフェナーとW.とS.Casner、「IP Multicastのための'トレースルート'施設」、Work。
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[6]、RFC1766、1995年3月。
[7] Handley, M. and S. Hanna. "Multicast Address Allocation
Protocol (AAP)", Work in Progress.
[7] ハンドレー、M.、およびS.ハンナ。 「マルチキャストアドレス配分プロトコル(AAP)」は進行中で働いています。
[8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward
Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,
Vancouver, Canada.
[8] R. カーモード、「前進型誤信号訂正(SHARQFEC)との見られたハイブリッド自動反復要求」、ACM SIGCOMM98、1998年9月、バンクーバー、カナダ。
[9] Hanna, S., Patel, B., and M. Shah. "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[9] ハンナ、S.、パテル、B.、およびM.シャー。 「マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)」、RFC2730、1999年12月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[10] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、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- アドレス注意/iana/課題/ファミリーナンバ
[12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[12] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
Handley, et al. Standards Track [Page 25] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[25ページ]。
11. Authors' Addresses
11. 作者のアドレス
Mark Handley AT&T Center for Internet Research at ICSI 1947 Center St, Suite 600 Berkely, CA 94704 USA
ICSI1947センター通り、600Berkely、スイートカリフォルニア94704米国でのインターネット調査のためのマークハンドレーAT&Tセンター
EMail: mjh@aciri.org
メール: mjh@aciri.org
David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA
デヴィッドターレルマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: dthaler@microsoft.com
メール: dthaler@microsoft.com
Roger Kermode Motorola Australian Research Centre 12 Lord St, Botany, NSW 2019 Australia
ロジャーカーモードモトローラのオーストラリアの研究センター12主の通り、植物学、NSW2019オーストラリア
EMail: Roger.Kermode@motorola.com
メール: Roger.Kermode@motorola.com
Handley, et al. Standards Track [Page 26] RFC 2776 MZAP February 2000
ハンドレー、他 規格はMZAP2000年2月にRFC2776を追跡します[26ページ]。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Handley, et al. Standards Track [Page 27]
ハンドレー、他 標準化過程[27ページ]
一覧
スポンサーリンク
