[要約] RFC 2908は、インターネットのマルチキャストアドレスの割り当てアーキテクチャに関するものであり、マルチキャストアドレスの割り当てと管理のためのガイドラインを提供しています。このRFCの目的は、効率的で一貫性のあるマルチキャストアドレスの割り当てを実現することです。
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.
Copyright（c）The Internet Society（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）を提案しています。アーキテクチャは、ホストサーバーメカニズム、ドメイン内サーバーサーバー調整メカニズム、およびドメイン間メカニズムを含む3つの層を備えたモジュラーです。
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:
ユニキャストアドレスと同様に、特定のマルチキャストアドレスの使用は2次元で制限されています。
Lifetime: An address has a start time and a (possibly infinite) end time, between which it is valid.
Lifetime：アドレスには、開始時間と（おそらく無限の）終了時間があり、その間に有効です。
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.
このアーキテクチャは、使用中の主要なスコーピングメカニズムがRFC 2365 [1]に記載されているように、管理監視であると想定しています。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.
適時性の観点からは、クライアントにその独自性に合理的な自信を持って住所が与えられる前に、最大数秒までの短い遅延はおそらく受け入れられます。セッションが事前に定義されている場合、住所はできるだけ早く割り当てられ、セッションが開始される直前まで待ってはいけません。セッションで使用されるマルチキャストアドレスを実際に開始するまでのマルチキャストアドレスを変更することは許容される場合がありますが、これは、初期セッションの定義の後に発見されたアドレス衝突などの重要な問題を回避する場合にのみ行う必要があります。
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.
アドレス空間が不足している状況では、アドレス空間を単純に分割すると、アドレス空間が大幅に断片化されます。これは、ネットワークパーティションが発生した場合には、アドレスをかなりの時間に割り当てることができるという合理的な程度の保証を与えるために、各アドレススペースパーティションに十分な予備スペースが必要になるためです。さらに、このような階層内のバックアップ割り当てサーバーを提供するために、フェールオーバー（サーバーのパーティション化と相互のバックアップを含む）が衝突により、アドレススペースの断片化がさらに追加されないようにします。
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.
静的アドレスは通常、永続的な寿命を持ち、スコープ範囲が存在する範囲で定義されています。そのため、静的アドレスはどこでも有効です（レシーバーのセットは場所によって異なる場合があります）、アプリケーション、デバイス、埋め込みシステムなどにハードコーディングされる場合があります。静的アドレスは、送信をサポートするデバイスにも役立ちますが、マルチキャストIPデータグラム（RFC 1112 [7]で指定されているレベル1の適合性）を受信していないか、ワイヤレスブロードキャストデバイスなどのデータをまったく受信できません。
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.
このアーキテクチャには3つのレイヤーがあります（図1）。これらのレイヤー番号は、データパケットのパスを説明する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.
このレイヤーでの可能なプロトコルまたはメカニズムの例には、MADCAP [4]、HTTPが割り当てのWebページにアクセスし、IANA静的アドレスの割り当てが含まれます。
An abstract API for applications to use for dynamic allocation, independent of the Layer 1 protocol/mechanism in use, is given in [11].
使用中のレイヤー1プロトコル/メカニズムとは無関係に、動的割り当てに使用するアプリケーションの要約APIは[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 domain内部プロトコルまたはメカニズムが、それらが重複したアドレスを割り当てないように割り当てを調整するために使用するメカニズム。MAAには、MAASの障害と再起動全体に一意性が保存されるように、MAAには安定したストレージ、または同等の堅牢性メカニズムが必要です。
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]で説明されているように数字による静的割り当て（プレフィックスコーディネーターは通常、ヒューマン管理者です）に含まれます。。
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.
管理スコープ内の動的アドレスを割り当てるには、MAAがどのスコープが有効なか、アドレスの範囲と名前が何であるか、各スコープ内のアドレスまたはサブレンジが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.
動的割り当てのサブレンジを決定するには、各スコープに2つのケースがあり、小さな「不可分な」スコープと大きな「分裂可能な」スコープに対応しています。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 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.
(1) 小さなスコープの場合、割り当てドメインは、管理範囲内のトポロジ全体に対応します。したがって、スコープ内のすべてのMAASSは、アドレス範囲全体（スコープ相関アドレスとして予約された最後の256アドレスを差し引いたもの）を使用し、レイヤー2メカニズム/プロトコルを使用して割り当てを調整することができます。小さなスコープの場合、プレフィックスコーディネーターは関与していません。
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メカニズム/プロトコルを使用して、割り当てドメインの中でスコープされたアドレス空間を分割する必要があります。したがって、MAAは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は、境界ではない割り当て範囲の境界の手動セットアップによって分割される可能性があります。これは、ユニキャストを2つ以上のマルチキャスト割り当てドメインに分割するマルチキャスト境界を設定することによって行われます。
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が独自の割り当てドメインである場合、アドレススペースの断片化が発生する可能性があります。ここでは、代わりにプロバイダーの割り当てドメインの一部として扱われ、レイヤー2プロトコル/メカニズムを使用して、MAAS（もしあれば）とプロバイダーの配分を調整します。次の場合、おそらくこの一連の行動を取るべきです。oそれが単一のプロバイダーに接続されている場合、
o it does not provide transit for another AS, and
o それは別のものに輸送を提供しません、そして
o it needs fewer than (say) 256 multicast addresses of larger than AS scope allocated on average.
o 平均して割り当てられたスコープよりも大きい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.
クライアントがマルチキャストアドレスを必要とする場合、最初に意図したセッションの範囲が何であるかを決定し、その範囲内でアドレスを割り当てることができるMAAを見つける必要があります。
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を見つけることは、SLP [12]などのサービスロケーションプロトコルを使用した手動構成を含むさまざまな方法、またはレイヤー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は、レイヤー2メカニズム/プロトコルを使用して、そのようなアドレスが他のMAASSによって割り当てられたアドレスと衝突しないようにします。たとえば、レイヤー2が非重複範囲の手動構成を使用している場合、これは単にローカルMAASで構成された範囲に付着することで構成されます。一方、AAPがレイヤー2で使用され、アドレススペースの断片化が少ない場合、MAASはAAPを使用して提案された割り当てドメイン全体を宣伝します。衝突AAP請求が短時間内に受信されない場合、レイヤー1プロトコル/メカニズムを介してアドレスがクライアントに返されます。MAASが衝突する請求を受け取った場合、それは別の住所を選択して再び試みます。また、AAPは、各MAAが衝突を検出するのを待つ必要がないアドレスの小さな「プール」を事前に予約することを可能にします。
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.
したがって、このアーキテクチャのレイヤーを実装するプロトコル/メカニズムは、安全な方法で展開できる必要があります。たとえば、ポリシーの制限で認証をサポートする必要があり、不正な人が別の当事者の割り当てをリリースまたは変更できるようにしてはなりません。
Steve Hanna provided valuable feedback on this document. The members of the MALLOC WG and the MBone community provided the motivation for this work.
Steve Hannaは、この文書に関する貴重なフィードバックを提供しました。Malloc WGとMboneコミュニティのメンバーは、この作業の動機を提供しました。
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[1] Meyer、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] Mark Handley、「マルチキャストセッションディレクトリとアドレス配分」、「スケーラブルマルチメディア会議システム」、ロンドン大学、1997年の博士論文の第6章。
[3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4 of PhD Thesis entitled "On Scalable Multimedia Conferencing Systems", University of London, 1997.
[3] Mark Handley、「Mbone Performanceの分析」、1997年ロンドン大学、「Scalable Multimedia Conferencing Systems」というタイトルの博士論文の第4章。
[4] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[4] Hanna、S.、Patel、B。およびM. Shah、「マルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）」、RFC 2730、1999年12月。
[5] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in Progress.
[5] Handley、M。およびS. Hanna、「マルチキャストアドレス割り当てプロトコル（AAP）」、作業進行中。
[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.、Govindan、R.、Handley、M.、Kumar、S.、Radoslavov、P。and D. Thaler、「マルチキャストアドレスセットクレーム（MASC）プロトコル」、RFC 2909、2000年9月。
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[7] Deering、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. Li、「ボーダーゲートウェイプロトコル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] Handley、M.、Thaler、D。、およびR. Kermode、「マルチキャストスコープゾーンアナウンスアナウンスプロトコル（MZAP）」、RFC 2776、2000年2月。
[10] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000.
[10] Meyer、D。およびP. Lothberg、「233/8のGlopアドレス指定」、RFC 2770、2000年2月。
[11] Finlayson, R., "Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[11] Finlayson、R。、「マルチキャストアドレス割り当ての要約API」、RFC 2771、2000年2月。
[12] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[12] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「Service Location Protocol、Version 2」、RFC 2608、1999年6月。
[13] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[13] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、1992年3月。
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: dthaler@microsoft.com
Mark Handley AT&T Center for Internet Research at ICSI 1947 Center St, Suite 600 Berkeley, CA 94704
ICSI 1947 Center St、Suite 600 Berkeley、CA 94704のMark Handley AT＆Tセンターのインターネット研究センター
EMail: mjh@aciri.org
Deborah Estrin Computer Science Dept/ISI University of Southern California Los Angeles, CA 90089
デボラエストリンコンピューターサイエンス部/南カリフォルニア大学ロサンゼルス大学90089
EMail: estrin@usc.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。