Network Working Group D. Thaler
Request for Comments: 2908 Microsoft
Category: Informational M. Handley
ACIRI
D. Estrin
ISI
September 2000
The Internet Multicast Address Allocation Architecture
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document proposes a multicast address allocation architecture (MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server-server coordination mechanism, and an inter-domain mechanism.
この文書は、インターネットのためのマルチキャストアドレス配分アーキテクチャ（MALLOC）を提案しています。アーキテクチャは、ホストサーバの機構、ドメイン内のサーバーのサーバー調整機構と、ドメイン間の機構を含む、三層を有するモジュラーです。
Table of Contents
目次
1: Introduction ................................................ 2
2: Requirements ................................................ 2
3.1: Address Dynamics .......................................... 4
3: Overview of the Architecture ................................ 5
4: Scoping ..................................................... 7
4.1: Allocation Scope .......................................... 8
4.1.1: The IPv4 Allocation Scope -- 239.251.0.0/16 ............. 9
4.1.2: The IPv6 Allocation Scope -- SCOP 6 ..................... 9
5: Overview of the Allocation Process .......................... 9
6: Security Considerations ..................................... 10
7: Acknowledgments ............................................. 11
8: References .................................................. 11
9: Authors' Addresses .......................................... 12
10: Full Copyright Statement ................................... 13
This document proposes a multicast address allocation architecture (MALLOC) for the Internet, and is intended to be generic enough to apply to both IPv4 and IPv6 environments.
この文書は、インターネットのためのマルチキャストアドレス配分アーキテクチャ（MALLOC）を提案し、IPv4とIPv6の両方の環境に適用するのに十分な汎用的であることを意図しています。
As with unicast addresses, the usage of any given multicast address is limited in two dimensions:
ユニキャストアドレスの場合と同様に、任意の所与のマルチキャストアドレスの使用は、二次元に制限されています。
Lifetime: An address has a start time and a (possibly infinite) end time, between which it is valid.
生涯：アドレスは、開始時刻と、それが有効である間（多分無限）終了時間を、持っています。
Scope: An address is valid over a specific area of the network. For example, it may be globally valid and unique, or it may be a private address which is valid only within a local area.
スコープ：アドレスは、ネットワークの特定の領域にわたり有効です。例えば、それは世界的に有効な一意であってもよいし、あるいはそれは、ローカルエリア内で有効なプライベートアドレスであってもよいです。
This architecture assumes that the primary scoping mechanism in use is administrative scoping, as described in RFC 2365 [1]. While solutions that work for TTL scoping are possible, they introduce significant additional complication for address allocation [2]. Moreover, TTL scoping is a poor solution for multicast scope control, and our assumption is that usage of TTL scoping will decline before this architecture is widely used.
このアーキテクチャは、[1] RFC 2365に記載されているように、使用中のプライマリスコープ機構は、管理スコープであることを前提としています。 TTLスコープのために働く解決策が可能であるが、それらはアドレス割当て[2]のための重要な追加の複雑さを導入します。また、TTLスコープは、マルチキャストスコープの制御用の乏しい溶液であり、そして我々の仮定は、このアーキテクチャが広く使用される前にTTLスコープの使用量が減少することです。
From a design point of view, the important properties of multicast allocation mechanisms are robustness, timeliness, low probability of clashing allocations, and good address space utilization in situations where space is scare. Where this interacts with multicast routing, it is desirable for multicast addresses to be allocated in a manner that aids aggregation of routing state.
設計の観点からは、マルチキャスト配分メカニズムの重要な特性は、堅牢性、適時性、衝突配分の低い確率、およびスペースは恐怖である状況で良いのアドレス空間の利用です。これは、マルチキャストルーティングと相互作用する場合、それは状態ルーティングの凝集を助けるように割り当てられるマルチキャストアドレスのために望ましいです。
o Robustness/Availability
O堅牢性/可用性
The robustness requirement is that an application requiring the allocation of an address should always be able to obtain one, even in the presence of other network failures.
ロバスト性の要件は、アドレスの割り当てを要求するアプリケーションは、常にも他のネットワーク障害の存在下で、いずれかを得ることができなければならないということです。
o Timeliness
Oの適時
From a timeliness point of view, a short delay of up to a few seconds is probably acceptable before the client is given an address with reasonable confidence in its uniqueness. If the session is defined in advance, the address should be allocated as soon as possible, and should not wait until just before the session starts. It is in some cases acceptable to change the multicast addresses used by the session up until the time when the session actually starts, but this should only be done when it averts a significant problem such as an address clash that was discovered after initial session definition.
クライアントは、そのユニークさで、合理的な自信を持ってアドレスを与えている前に、ビューの適時性の観点から、数秒までの短い遅延は、おそらく許容可能です。セッションは事前に定義されている場合、アドレスはできるだけ早く割り当てられるべきである、とのセッションが始まる前にちょうどまで待つべきではありません。セッションが実際に開始時間まで、セッションアップで使用されるマルチキャストアドレスを変更するには、いくつかのケースでは許容ですが、それは、このような初期のセッション定義の後に発見されたアドレス衝突など重大な問題をaverts場合にのみ行われるべきです。
o Low Probability of Clashes
衝突のO低い確率
A multicast address allocation scheme should always be able to allocate an address that can be guaranteed not to clash with that of another session. A top-down partitioning of the address space would be required to completely guarantee that no clashes would occur.
マルチキャストアドレスの割り当て方式は、常に他のセッションのそれと衝突しないことが保証できるアドレスを割り当てることができるはずです。アドレス空間のトップダウン分割は完全に何の衝突が起こらないことを保証するために必要とされるであろう。
o Address Space Packing in Scarcity Situations
希少な状況で梱包Oアドレス空間
In situations where address space is scarce, simply partitioning the address space would result in significant fragmentation of the address space. This is because one would need enough spare space in each address space partition to give a reasonable degree of assurance that addresses could still be allocated for a significant time in the event of a network partition. In addition, providing backup allocation servers in such a hierarchy, so that fail-over (including partitioning of a server and its backup from each other) does not cause collisions would add further to the address space fragmentation.
アドレス空間が不足している状況では、単にアドレス空間を分割することは、アドレス空間の大幅な断片化につながります。 1のアドレスは、まだネットワークパーティションの場合にはかなりの時間のために割り当てることができることを保証する合理的な程度を与えるために、各アドレス空間のパーティションに十分な予備スペースを必要とするためです。 （サーバーと互いにそのバックアップのパーティションを含む）は、フェイルオーバは衝突がアドレス空間の断片化にさらに追加することになり引き起こさないように加えて、このような階層でバックアップ割り当てサーバを提供します。
Since guaranteeing no clashes in a robust manner requires partitioning the address space, providing a hard guarantee leads to inefficient address space usage. Hence, when address space is scarce, it is difficult to achieve constant availability and timeliness, guarantee no clashes, and achieve good address space usage. As a result, we must prioritize these properties. We believe that, when address space is scarce, achieving good address space packing and constant availability are more important than guaranteeing that address clashes never occur. What we aim for in these situations is a very high probability that an address clash does not occur, but we accept that there is a finite probability of this happening. Should a clash occur (or should an application start using an address it did not allocate, which may also lead to a clash), either the clash can be detected and addresses changed, or hosts receiving additional traffic can prune that traffic using source-specific prunes available in IGMP version 3, and so we do not believe that this is a disastrous situation.
ハード保証を提供し、アドレス空間を分割する必要が堅牢な方法で何の衝突を保証していないので、非効率的なアドレス空間の使用率につながります。アドレス空間が不足しているときしたがって、一定の可用性と適時性を達成一切衝突を保証していない、との良好なアドレス空間の使用率を達成することは困難です。その結果、我々はこれらのプロパティに優先順位を付けなければなりません。我々は良いアドレス空間のパッキングと一定の可用性を実現し、アドレス空間が不足しているとき、と信じているアドレスの衝突が発生しないことを保証するよりも重要です。私たちはこのような状況でを目指すことはアドレス衝突が発生していない可能性が非常に高いですが、私たちはこの出来事の有限の確率があることを受け入れます。衝突が発生しなければならない（またはアプリケーションはまた、衝突につながる可能性があり、それが割り当てられませんでしたアドレスを使用して開始する必要が）、いずれかの衝突を検出することができ、アドレスが変更、または追加のトラフィックを受信するホストがトラフィックソース固有使用することを整理することができIGMPバージョン3で利用可能なプルーン、そして私たちは、これは悲惨な状況であることを信じていません。
In summary, tolerating the possibility of clashes is likely to allow allocation of a very high proportion of the address space in the presence of network conditions such as those observed in [3].
要約すると、衝突の可能性を許容することは、[3]で観察されたもののようなネットワーク条件の存在下でのアドレス空間の非常に高い割合の割り当てを可能にする可能性があります。
We believe that we can get good packing and good availability with good collision avoidance, while we would have to compromise packing and availability significantly to avoid all collisions.
我々は、すべての衝突を避けるために、大幅に梱包し、可用性を犠牲にする必要がありますしながら、私たちは、優れた衝突回避との良好な梱包と良い可用性を得ることができると信じています。
Finally, in situations where address space is not scarce, such as with IPv6, achieving good address space usage is less important, and hence partitioning may potentially be used to guarantee no collisions among hosts that use this architecture.
最後に、IPv6で、アドレス空間が不足しない状況では、良好なアドレス空間の使用を達成することはあまり重要であるので、分割は、潜在的にこのアーキテクチャを使用するホストの間には衝突を保証しないために使用されてもよいです。
Multicast addresses may be allocated in any of three ways:
マルチキャストアドレスは、3つのいずれかの方法で割り当てることがあります。
Static: Statically allocated addresses are allocated by IANA for specific protocols that require well-known addresses to work. Examples of static addresses are 224.0.1.1 which is used for the Network Time Protocol [13] and 224.2.127.255 which is used for global scope multicast session announcements. Applications that use multicast for bootstrap purposes should not normally be given their own static multicast address, but should bootstrap themselves using a well-known service location address which can be used to announce the binding between local services and multicast addresses.
静的：静的に割り当てられたアドレスが機能するように、よく知られているアドレスを必要とする特定のプロトコルのためにIANAによって割り当てられています。静的アドレスの例は、グローバルスコープのマルチキャストセッション告知のために使用されるネットワーク時間プロトコル[13]と224.2.127.255のために使用される224.0.1.1です。ブートストラップの目的のためにマルチキャストを使用するアプリケーションは、通常、独自のスタティックマルチキャストアドレスを与えられるべきではなく、ローカルサービスとマルチキャストアドレスの間の結合を発表するために使用することができ、よく知られたサービス・ロケーション・アドレスを使用して自分自身をブートストラップする必要があります。
Static addresses typically have a permanent lifetime, and a scope defined by the scope range in which they reside. As such, a static address is valid everywhere (although the set of receivers may be different depending on location), and may be hard-coded into applications, devices, embedded systems, etc. Static addresses are also useful for devices which support sending but not receiving multicast IP datagrams (Level 1 conformance as specified in RFC 1112 [7]), or even are incapable of receiving any data at all, such as a wireless broadcasting device.
静的アドレスは、典型的には、永久的な寿命を有し、そしてそれらが存在する範囲の範囲によって定義される範囲。等、（受信機のセットが場所によって異なっていてもよいが）のような、静的アドレスはどこにでも有効であり、アプリケーション、デバイス、組み込みシステム内にハードコード化することができる静的アドレスも送信が、サポートするデバイスのために有用です（[7] RFC 1112で指定されるように、レベル1準拠）、あるいはそのような無線放送装置として、まったくデータを受信することができないマルチキャストIPデータグラムを受信していません。
Scope-relative: RFC 2365 [1] reserves the highest 256 addresses in every administrative scope range for relative assignments. Relative assignments are made by IANA and consist of an offset which is valid in every scope. Relative addresses are reserved for infrastructure protocols which require an address in every scope, and this offset may be hard-coded into applications, devices, embedded systems, etc. Such devices must have a way (e.g. via MZAP [9] or via MADCAP [4]) to obtain the list of scopes in which they reside.
スコープ相対：RFC 2365 [1]に対して割り当てごとに管理スコープの範囲で最高256のアドレスを予約します。相対的な割り当てはIANAによって行われた、すべての範囲で有効であるオフセットで構成されています。相対アドレスは、[すべての範囲内のアドレスを必要とするインフラプロトコルのために予約され、このオフセットアプリケーション、デバイス、組み込みシステム内にハードコード化することができる、等そのようなデバイスは、方法を有していなければならない（例えばMZAP介し[9]またはMADCAP介しれます4]）は、それらが存在するスコープのリストを取得します。
The offsets assigned typically have a permanent lifetime, and are valid in every scope and location. Hence, the scope-relative address in a given scope range has a lifetime equal to that of the scope range in which it falls.
一般的に割り当てられたオフセットは永久的な寿命を有し、かつすべての範囲や場所に有効です。したがって、所与の範囲の範囲内スコープ相対アドレスは、それが属するスコープの範囲と同等の寿命を有します。
Dynamic: For most purposes, the correct way to use multicast is to obtain a dynamic multicast address. These addresses are provided on demand and have a specific lifetime. An application should request an address only for as long as it expects to need the address. Under some circumstances, an address will be granted for a period of time that is less than the time that was requested. This will occur rarely if the request is for a reasonable amount of time. Applications should be prepared to cope with this when it occurs.
ダイナミック：ほとんどの目的のために、マルチキャストを使用するための正しい方法は、動的マルチキャストアドレスを取得することです。これらのアドレスは、オンデマンドで提供し、特定の寿命を持っています。アプリケーションは、それがアドレスを必要とすることを期待としてのみアドレスを要求すべきです。いくつかの状況下では、アドレスが要求された時間より少ない時間の付与されます。要求が妥当な時間のためである場合、これはまれにしか発生しません。アプリケーションは、それが発生したときにこれに対処するために準備する必要があります。
At any time during the lifetime of an existing address, applications may also request an extension of the lifetime, and such extensions will be granted when possible. When the address extension is not granted, the application is expected to request a new address to take over from the old address when it expires, and to be able to cope with this situation gracefully. As with unicast addresses, no guarantee of reachability of an address is provided by the network once the lifetime expires.
既存のアドレスの有効期間中はいつでも、アプリケーションはまた、寿命の延長を要求すること、及びそのような拡張が可能な場合に付与されます。アドレス拡張が許可されていない場合、アプリケーションは、それが期限切れになったときに、古いアドレスから引き継ぐために、そして優雅にこのような状況に対処できるように、新しいアドレスを要求することが期待されます。寿命が満了した後にユニキャストアドレスと同じように、アドレスの到達性の保証は、ネットワークによって提供されていません。
These restrictions on address lifetime are necessary to allow the address allocation architecture to be organized around address usage patterns in a manner that ensures addresses are aggregatable and multicast routing is reasonably close to optimal. In contrast, statically allocated addresses may be given sub-optimal routing.
アドレス寿命にこれらの制限は、アドレス割当アーキテクチャはアドレスが集約され、マルチキャストルーティングが最適に合理的に近接してい保証するようにアドレスの使用パターンを中心に構成されることを可能にするために必要です。対照的に、静的に割り当てられたアドレスは、準最適ルーティングを与えることができます。
The architecture is modular so that each layer may be used, upgraded, or replaced independently of the others. Layering also provides isolation, in that different mechanisms at the same layer can be used by different organizations without adversely impacting other layers.
各層は、使用されるアップグレード、又は互いに独立に置き換えられてもよいように、アーキテクチャはモジュラーです。積層は、同一層に、異なるメカニズムが悪影響他の層に影響を与えることなく、異なる組織で使用することができるでは、分離を提供します。
There are three layers in this architecture (Figure 1). Note that these layer numbers are different from the layer numbers in the TCP/IP stack, which describe the path of data packets.
このアーキテクチャ（図1）内の3つの層があります。これらの層の数は、データパケットの経路を説明TCP / IPスタックのレイヤ番号とは異なることに留意されたいです。
+--------------------------+ +------------------------+
| | | |
| to other peers | | to other peers |
| || // | | || // || |
| Prefix | | Prefix Prefix |
| Coordinator | |Coordinator Coordinator|
+------------||------------+ +-------||----//---------+
||Layer 3 || //
+------------||------------------------------||--//-----------+
| Prefix Prefix |
| Coordinator=======================Coordinator |
| ^ ^ |
| +----------------+-------------+ |
| | Layer 2 | | |
| MAAS<---/ | +---> MAAS |
| ^ ^ v ^ |
| . . MAAS . |
| . .Layer 1 ^ .Layer 1 |
| v v .Layer 1 v |
| Client Client v Client |
| Client |
+-------------------------------------------------------------+
Figure 1: An Overview of the Multicast Address Allocation Architecture
図1：マルチキャストアドレス配分アーキテクチャの概要
Layer 1 A protocol or mechanism that a multicast client uses to request a multicast address from a multicast address allocation server (MAAS). When the server grants an address, it becomes the server's responsibility to ensure that this address is not then reused elsewhere within the address's scope during the lifetime granted.
層1マルチキャストクライアントは、マルチキャストアドレス割り当てサーバ（MAAS）からマルチキャストアドレスを要求するために使用するプロトコル又はメカニズム。サーバーがアドレスを付与する場合は、このアドレスはその後、付与された寿命の間にアドレスの範囲内で他の場所で再利用されていないことを確認するために、サーバー側の責任になります。
Examples of possible protocols or mechanisms at this layer include MADCAP [4], HTTP to access a web page for allocation, and IANA static address assignments.
この層の可能なプロトコルまたは機構の例には、割り当てのためのWebページにアクセスするMADCAP [4]、HTTP、およびIANA静的アドレス割り当てを含みます。
An abstract API for applications to use for dynamic allocation, independent of the Layer 1 protocol/mechanism in use, is given in [11].
アプリケーションは、動的割り当てに使用するための抽象APIは、使用中のレイヤ1つのプロトコル/メカニズムとは無関係に、[11]に記載されています。
Layer 2 An intra-domain protocol or mechanism that MAAS's use to coordinate allocations to ensure they do not allocate duplicate addresses. A MAAS must have stable storage, or some equivalent robustness mechanism, to ensure that uniqueness is preserved across MAAS failures and reboots.
レイヤ2 MAASの使用は、彼らが重複アドレスを割り当てないように配分を調整するドメイン内のプロトコルやメカニズム。 MAASは一意性がMAASの障害や再起動しても維持されることを保証するために、貯蔵安定性、または何らかの同等の堅牢性のメカニズムを持っている必要があります。
MAASs also use the Layer 2 protocol/mechanism to acquire (from "Prefix Coordinators") the ranges of multicast addresses out of which they may allocate addresses.
Maass第また、それらがアドレスを割り当てることができるのうちマルチキャストアドレスの範囲（「プレフィックスコーディネーター」から）を取得するために、レイヤ2プロトコル/メカニズムを使用します。
In this document we use the term "allocation domain" to mean an administratively scoped multicast-capable region of the network, within which addresses in a specific range may be allocated by a Layer 2 protocol/mechanism.
この文書では、レイヤ2プロトコル/メカニズムによって割り当てられてもよい特定の範囲のアドレスその内部ネットワークの管理スコープマルチキャスト可能な領域を意味する用語「割当ドメイン」を使用します。
Examples of protocols or mechanisms at this layer include AAP [5], and manual configuration of MAAS's.
この層におけるプロトコルまたはメカニズムの例は、AAP [5]、及びMAAS者の手動設定を含みます。
Layer 3 An inter-domain protocol or mechanism that allocates multicast address ranges (with lifetimes) to Prefix Coordinators. Individual addresses may then be allocated out of these ranges by MAAS's inside allocation domains as described above.
レイヤ3プレフィックスコーディネーターへのドメイン間のプロトコルまたは（寿命で）マルチキャストアドレス範囲を割り当てるメカニズム。上記のように個々のアドレスは、次いでMAASの内部割当ドメインによりこれらの範囲の外に割り当てることができます。
Examples of protocols or mechanisms at this layer include MASC [6] (in which Prefix Coordinators are typically routers without any stable storage requirement), and static allocations by AS number as described in [10] (in which Prefix Coordinators are typically human administrators).
この層におけるプロトコルまたはメカニズムの例としては、MASC [6]（式中、接頭コーディネーターは、典型的には、任意の安定な貯蔵を必要とせずルータ）、および[10]に記載のようにAS番号によって静的割り当て（ここでは、プレフィックスコーディネーターは、典型的には、人間の管理者です） 。
Each of the three layers serves slightly different purposes and as such, protocols or mechanisms at each layer may require different design tradeoffs.
3層の各々は、わずかに異なる目的を果たすそのようなものとして、各層におけるプロトコルまたはメカニズムは、異なる設計のトレードオフを必要とするかもしれません。
To allocate dynamic addresses within administrative scopes, a MAAS must be able to learn which scopes are in effect, what their address ranges and names are, and which addresses or subranges within each scope are valid for dynamic allocation by the MAAS.
管理スコープ内の動的アドレスを割り当てるには、MAASは、そのアドレス範囲と名前が何であるか、有効になっているどのスコープ学ぶことができる、そしてどのアドレスまたは各範囲内のサブレンジがMAASによる動的割り当てのために有効である必要があります。
The first two tasks, learning the scopes in effect and the address range and name(s) of each scope, may be provided by static configuration or dynamically learned. For example, a MAAS may simply passively listen to MZAP [9] messages to acquire this information.
効果およびアドレス範囲と、各スコープの名前（複数可）にスコープを学習最初の2つのタスクが、静的な構成によって提供されるか、または動的に学習することができます。例えば、MAASは単に受動的にこの情報を取得するMZAP〜[9]のメッセージを聞くことができます。
To determine the subrange for dynamic allocation, there are two cases for each scope, corresponding to small "indivisible" scopes, and big "divisible" scopes. Note that MZAP identifies which scopes are divisible and which are not.
動的割り当てのサブレンジを決定するために、二つの小さな「不可分」スコープに対応する各スコープの場合、大きな「倍数」のスコープがあります。スコープが割り切れるとMZAPの識別ではないことに注意してください。
(1) For small scopes, the allocation domain corresponds to the entire topology within the administrative scope. Hence, all MAASs inside the scope may use the entire address range (minus the last
（1）小さなスコープの、割り当てドメインは、管理範囲内全体のトポロジーに対応しています。従って、範囲内のすべてのMaass第全体アドレス範囲（マイナス最後を使用することができます
256 addresses reserved as scope-relative addresses), and use the
Layer 2 mechanism/protocol to coordinate allocations. For small
scopes, Prefix Coordinators are not involved.
Hence, for small scopes, the effective "allocation domain" area may be different for different scopes. Note that a small, indivisible scope could be larger or smaller than the Allocation Scope used for big scopes (see below).
したがって、小さなスコープのため、効果的な「割当ドメイン」領域は、異なるスコープの異なっていてもよいです。小さな、不可分範囲大きなスコープ（下記参照）に使用される割り当て範囲よりも大きくても小さくあり得ることに留意されたいです。
(2) For big scopes (including the global scope), the area inside the scope may be large enough that simply using a Layer 2 mechanism/protocol may be inefficient or otherwise undesirable. In this case, the scope must span multiple allocation domains, and the Layer 3 mechanism/protocol must be used to divvy up the scoped address space among the allocation domains. Hence, a MAAS may learn of the scope via MZAP, but must acquire a subrange from which to allocate from a Prefix Coordinator.
（2）（グローバルスコープを含む）大きなスコープのスコープ内の領域は、単にレイヤ2機構/プロトコルを使用して非効率的なまたは他の望ましくないかもしれないことは十分に大きくてもよいです。この場合、範囲は、複数の割り当てドメインにまたがる必要があり、レイヤ3機構/プロトコルが割り当てドメイン間スコープアドレス空間をDIVVYするために使用されなければなりません。したがって、MAASはMZAP介し範囲を学習することができるが、プリフィックス・コーディネーターから割り当てることからサブレンジを取得する必要があります。
For simplicity, the effective "allocation domain" area will be
the same for all big scopes, being the granularity at which all
big scopes are divided up. We define the administrative scope at
this granularity to be the "Allocation Scope".
The Allocation Scope is a new administrative scope, defined in this document and to be reserved by IANA with values as noted below. This is the scope that is used by a Layer 2 protocol/mechanism to coordinate address allocation for addresses in larger, divisible scopes.
割り当て範囲は新しい管理スコープ、本文書で定義され、以下に示すような値とIANAによって予約されます。これは、より大きな、分割スコープ内のアドレスのためのアドレス割り当てを調整するために、レイヤ2プロトコル/メカニズムによって使用される範囲です。
We expect that the Allocation Scope will often coincide with a unicast Autonomous System (AS) boundary.
当社は、割当対象範囲は、多くの場合、ユニキャスト自律システム（AS）の境界と一致することを期待しています。
If an AS is too large, or the network administrator wishes to run different intra-domain multicast routing in different parts of an AS, that AS can be split by manual setup of an allocation scope boundary that is not an AS boundary. This is done by setting up a multicast boundary dividing the unicast AS into two or more multicast allocation domains.
ASは大きすぎる、またはネットワーク管理者は、ASがないAS境界で割り当てスコープ境界の手動設定によって分割することができ、ASの異なる部分で異なるドメイン内のマルチキャストルーティングを実行したい場合。これは、2つの以上のマルチキャスト割当ドメインにASユニキャストを分割マルチキャスト境界を設定することによって行われます。
If an AS is too small, and address space is scarce, address space fragmentation may occur if the AS is its own allocation domain. Here, the AS can instead be treated as part of its provider's allocation domain, and use a Layer 2 protocol/mechanism to coordinate allocation between its MAAS's (if any) and those of its provider. An AS should probably take this course of action if: o it is connected to a single provider,
ASが小さすぎると、アドレス空間が不足しているかのように、独自の割り当てドメインの場合は、アドレス空間の断片化が発生することがあります。ここで、ASは、代わりに、そのプロバイダの割り当てドメインの一部として扱われ、そのMAASの（もしあれば）およびそのプロバイダのものとの間の割り当てを調整するために、レイヤ2プロトコル/メカニズムを使用することができます。 ASは、おそらく場合は、アクションのこのコースを取る必要があります。それは、単一のプロバイダに接続されているO、
o it does not provide transit for another AS, and
Oそれは別のASのための輸送を提供していない、と
o it needs fewer than (say) 256 multicast addresses of larger than AS scope allocated on average.
Oそれは平均して割り当てられたスコープASより大きい256のマルチキャストアドレス（例えば）よりも少ないが必要です。
The address space 239.251.0.0/16 is to be reserved for the Allocation Scope. The ranges 239.248.0.0/16, 239.249.0.0/16 and 239.250.0.0/16 are to be left unassigned and available for expansion of this space. These ranges should be left unassigned until the 239.251.0.0/16 space is no longer sufficient.
アドレス空間239.251.0.0/16は割り当て範囲のために予約されます。範囲239.248.0.0/16、239.249.0.0/16と239.250.0.0/16は、この空間の拡大のために割り当てられていないと利用可能なままにすることになっています。 239.251.0.0/16スペースはもはや十分になるまで、これらの範囲は、未割り当てのままにすべきではありません。
The IPv6 "scop" value 6 is to be used for the Allocation Scope.
IPv6の「SCOP」値6は、割り当て範囲に使用されます。
Once Layer 3 allocation has been performed for large, divisible scopes, and each Prefix Coordinator has acquired one or more ranges, then those ranges are passed to all MAAS's within the Prefix Coordinator's domain via a Layer 2 mechanism/protocol.
レイヤ3の割り当てが大きく、分割スコープのために行われており、各プレフィックス・コーディネーターは、1つ以上の範囲を取得した後、次いで、これらの範囲は、レイヤ2機構/プロトコルを介しプレフィックス・コーディネーターのドメイン内のすべてのMAAS年代に渡されます。
MAAS's within the domain receive these ranges and store them as the currently allowable addresses for that domain. Each range is valid for a given lifetime (also acquired via the Layer 3 mechanism/protocol) and is not revoked before the lifetime has expired. MAAS's also learn of small scopes (e.g., via MZAP) and store the ranges associated with them.
MAASのドメイン内では、これらの範囲を受け取り、そのドメインの現在の許容アドレスとして格納します。各範囲は、（また、レイヤ3機構/プロトコルを介して取得された）所定の寿命のために有効であり、寿命が満了する前に失効していません。 MAASのも（MZAPを経て、例えば）小さなスコープで学び、それらに関連付けられている範囲を格納します。
Using the Layer 2 mechanism/protocol, each MAAS ensures that it will exclude any addresses which have been or will be allocated by other MAAS's within its domain.
レイヤ2メカニズム/プロトコルを使用して、各MAASは、それがされているか、そのドメイン内の他のMAASさんによって割り当てられます任意のアドレスを除外するようになります。
When a client needs a multicast address, it first needs to decide what the scope of the intended session should be, and locate a MAAS capable of allocating addresses within that scope.
クライアントがマルチキャストアドレスを必要とするとき、それは最初に意図したセッションの範囲がどうあるべきかを決め、その範囲内のアドレスを割り当てることができMAASを検索する必要があります。
To pick a scope, the client will either simply choose a well-known scope, such as the global scope, or it will enumerate the available scopes (e.g., by sending a MADCAP query, or by listening to MZAP messages over time) and allow a user to select one.
範囲を選択するには、クライアントは、どちらかの単純なグローバルスコープなどのよく知られた範囲を、選択する、またはそれが可能なスコープ（例えば、MADCAPクエリを送信することにより、または時間をかけてメッセージをMZAPを聞くことによって）を列挙し、できるようになりますユーザは、1つを選択します。
Locating a MAAS can be done via a variety of methods, including manual configuration, using a service location protocol such as SLP [12], or via a mechanism provided by a Layer 1 protocol itself. MADCAP, for instance, includes such a facility.
MAASを配置[12]そのようなSLPなどのサービス・ロケーション・プロトコルを使用して、手動で設定を含む様々な方法を介して行うことができ、またはレイヤ1プロトコル自体によって提供される機構を介して。 MADCAPは、例えば、そのような施設を含みます。
Once the client has chosen a scope and located a MAAS, it then requests an address in that scope from the MAAS located. Along with the request it also passes the acceptable range for the lifetimes of the allocation it desires. For example, if the Layer 1 protocol in use is MADCAP, the client sends a MADCAP REQUEST message to the MAAS, and waits for a NAK message or an ACK message containing the allocated information.
クライアントは、スコープを選択し、MAASを設置したら、それはその後にあるMAASからそのスコープ内のアドレスを要求します。要求と共に、それはまた、それが望む割り当ての寿命の許容範囲を通過します。使用中のレイヤ1つのプロトコルはMADCAPされている場合、クライアントはMAASにMADCAP要求メッセージを送信し、NAKメッセージまたは割り当て情報を含むACKメッセージを待ちます。
Upon receiving a request from a client, the MAAS then chooses an unused address in a range for the specified scope, with a lifetime which both satisfies the acceptable range specified by the client, and is within the lifetime of the actual range.
クライアントからの要求を受信すると、MAASは両方がクライアントによって指定された許容範囲を満たす寿命と、指定されたスコープの範囲内の未使用のアドレスを選択し、実際の範囲の有効期間内です。
The MAAS uses the Layer 2 mechanism/protocol to ensure that such an address does not clash with any addresses allocated by other MAASs. For example, if Layer 2 uses manual configuration of non-overlapping ranges, then this simply consists of adhering to the range configured in the local MAAS. If, on the other hand, AAP is used at Layer 2 to provide less address space fragmentation, the MAAS advertises the proposed allocation domain-wide using AAP. If no clashing AAP claim is received within a short time interval, then the address is returned to the client via the Layer 1 protocol/mechanism. If a clashing claim is received by the MAAS, then it chooses a different address and tries again. AAP also allows each MAAS to pre-reserve a small "pool" of addresses for which it need not wait to detect clashes.
MAASは、アドレスが他のMaass第によって割り当てられたアドレスと競合しないことを確実にするために、レイヤ2機構/プロトコルを使用します。レイヤ2は、非重複範囲の手動設定を使用する場合、例えば、これは単にローカルMAASで設定範囲に付着から成ります。一方、AAPは、より少ないアドレス空間の断片化を提供するために、レイヤ2で使用されている場合は、MAASは、提案された割り当てドメイン全体の使用AAPをアドバタイズします。何の激突を行うAAPの主張は、短い時間間隔内に受信されない場合、アドレスは、レイヤ1プロトコル/機構を介してクライアントに返されます。衝突項はMAASにより受信された場合、それは別のアドレスを選択し、再度試みます。 AAPは、各MAASは、それが衝突を検出するのを待つ必要はありませんそのためのアドレスの小さな「プール」を事前に予約することができます。
If a domain ever begins to run out of available multicast addresses, a Prefix Coordinator in that domain uses the Layer 3 protocol/mechanism to acquire more space.
ドメインは、これまで利用可能なマルチキャストアドレスが不足し始めた場合、そのドメイン内のプレフィックスコーディネーターはより多くのスペースを取得するために、レイヤ3プロトコル/メカニズムを使用しています。
The architecture described herein does not prevent an application from just sending to or joining a multicast address without allocating it (just as the same is true for unicast addresses today). However, there is no guarantee that data for unallocated addresses will be delivered by the network. That is, routers may drop data for unallocated addresses if they have some way of checking whether a destination address has been allocated. For example, if the border routers of a domain participate in the Layer 2 protocol/mechanism and cache the set of allocated addresses, then data for unallocated addresses in a range allocated by that domain can be dropped by creating multicast forwarding state with an empty outgoing interface list and/or pruning back the tree branches for those groups.
本明細書に記載のアーキテクチャは、単に（同じユニキャストアドレスのために今日真であると同様）への送信、またはそれを割り当てず、マルチキャストアドレスに参加するアプリケーションを妨げません。ただし、未割り当てのアドレスのデータをネットワークで配信される保証はありません。すなわち、それらは宛先アドレスが割り当てられているかどうかをチェックするいくつかの方法を持っている場合、ルータは、未割り当てのアドレスのデータをドロップすること、です。ドメインの境界ルータは、レイヤ2プロトコル/メカニズムに参加し、割り当てられたアドレスのセットをキャッシュする場合、例えば、そのドメインによって割り当てられた範囲内の割り当てられていないアドレスのデータが空の送信とマルチキャスト転送状態を作成することによって落下させることができますインタフェースリストおよび/またはそれらのグループのための木の枝を剪定バック。
A malicious application may attempt a denial-of-service attack by attempting to allocate a large number of addresses, thus attempting to exhaust the supply of available addresses. Other attacks include releasing or modifying the allocation of another party. These attacks can be combatted through the use of authentication with policy restrictions (such as a maximum number of addresses that can be allocated by a single party).
悪意のあるアプリケーションは、このように利用可能なアドレスの供給を排出しようとし、アドレスの大きい数を割り当てることを試みることによってサービス拒否攻撃を試みることができます。他の攻撃は、他の当事者の割り当てを解除するか、修正することがあります。これらの攻撃は、（例えば、単一の当事者によって割り当て可能なアドレスの最大数など）ポリシー制限による認証を使用して闘おすることができます。
Hence, protocols/mechanisms that implement layers of this architecture should be deployable in a secure fashion. For example, one should support authentication with policy restrictions, and should not allow someone unauthorized to release or modify the allocation of another party.
したがって、このアーキテクチャの層を実現するプロトコル/メカニズムは、安全な方法で配置可能であるべきです。例えば、1は、ポリシーの制限を使用した認証をサポートする必要があり、不正誰かが他の当事者の割り当てを解除するか、変更することができないようにしてください。
Steve Hanna provided valuable feedback on this document. The members of the MALLOC WG and the MBone community provided the motivation for this work.
スティーブ・ハンナは、この文書の貴重なフィードバックを提供します。 MALLOC WGとあるMBoneコミュニティのメンバーは、この作品のためにモチベーションを与えました。
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[1]マイヤー、D.、 "管理用スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[2] Mark Handley, "Multicast Session Directories and Address Allocation", Chapter 6 of PhD Thesis entitled "On Scalable Multimedia Conferencing Systems", University of London, 1997.
[2]マーク・ハンドリー、「マルチキャストセッションディレクトリとアドレスの割り当て」、「スケーラブルマルチメディア会議システムでは」と題した博士論文の第6章、ロンドン、1997年の大学。
[3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4 of PhD Thesis entitled "On Scalable Multimedia Conferencing Systems", University of London, 1997.
[3]マーク・ハンドリー、「MBONEパフォーマンスのアン分析」、博士論文の第4章では、ロンドン大学、1997年「スケーラブルなマルチメディア会議システムでは」と題します。
[4] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[4]ハンナ、S.、パテル、B.及びM.シャー、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、1999年12月。
[5] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in Progress.
[5]ハンドレー、M.およびS.ハンナ、 "マルチキャストアドレス割り当てプロトコル（AAP）"、ProgressのWork。
[6] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov, P. and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000.
[6] Estrin、D.、ゴヴィンダン、R.、ハンドレー、M.、クマー、S.、Radoslavov、P。およびD.ターレル、 "マルチキャストアドレスセットクレーム（MASC）プロトコル"、RFC 2909、2000年9月。
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[7]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[8] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[9] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[9]ハンドレー、M.、ターラー、D.およびR. Kermode、 "マルチキャストスコープゾーン発表プロトコル（MZAP）"、RFC 2776、2000年2月。
[10] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000.
[10]マイヤー、D.とP. Lothberg、 "8分の233でアドレッシングGLOP"、RFC 2770、2000年2月。
[11] Finlayson, R., "Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[11]フィンレイソン、R.、RFC 2771、2000年2月 "マルチキャストアドレスの割り当てのための抽象API"。
[12] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[12]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[13] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[13]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
デーブターラーマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: dthaler@microsoft.com
メールアドレス：dthaler@microsoft.com
Mark Handley AT&T Center for Internet Research at ICSI 1947 Center St, Suite 600 Berkeley, CA 94704
マーク・ハンドリーAT＆ICSI 1947センターセントでインターネットリサーチのためのTセンター、スイート600バークレー、CA 94704
EMail: mjh@aciri.org
メールアドレス：mjh@aciri.org
Deborah Estrin Computer Science Dept/ISI University of Southern California Los Angeles, CA 90089
南カリフォルニアロサンゼルスのデボラ・エストリンコンピュータサイエンス学部/ ISI大学、CA 90089
EMail: estrin@usc.edu
メールアドレス：estrin@usc.edu
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機能のための基金は現在、インターネット協会によって提供されます。