RFC2908 日本語訳
2908 The Internet Multicast Address Allocation Architecture. D.Thaler, M. Handley, D. Estrin. September 2000. (Format: TXT=30515 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Thaler
Request for Comments: 2908 Microsoft
Category: Informational M. Handley
ACIRI
D. Estrin
ISI
September 2000
ターレルがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2908年のマイクロソフトカテゴリ: 情報のM.ハンドレーACIRI D.Estrin ISI2000年9月
The Internet Multicast Address Allocation Architecture
インターネットマルチキャストアドレス配分構造
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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
1: 序論… 2 2: 要件… 2 3.1: 力学を記述してください… 4 3: 構造の概観… 5 4: 見ます… 7 4.1: 配分範囲… 8 4.1.1: IPv4配分範囲--239.251 .0 .0 /16… 9 4.1.2: IPv6配分範囲--SCOP6… 9 5: 割当過程の概観… 9 6: セキュリティ問題… 10 7: 承認… 11 8: 参照… 11 9: 作者のアドレス… 12 10: 完全な著作権宣言文… 13
Thaler, et al. Informational [Page 1] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [1ページ]情報のRFC2908MALLOC構造2000年9月
1. Introduction
1. 序論
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.
この構造は、RFC2365[1]で説明されるように使用中の第一の見るメカニズムが見ながら管理であると仮定します。 TTLの見るために働いている解決策が可能である間、それらはアドレス配分[2]のための重要な追加複雑さを導入します。 そのうえ、TTLの見るのはマルチキャスト範囲制御装置の貧しい解決策です、そして、私たちの仮定はこの構造が広く使用される前にTTLの見ることの用法が減退するということです。
2. Requirements
2. 要件
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.
丈夫さ要件はアドレスの配分を必要とするアプリケーションがいつも1つを得ることができるべきであるということです、他のネットワーク失敗があるときさえ。
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
タイムリー観点から、ユニークさにおける妥当な自信を伴うアドレスをクライアントに与える前に上の少し数秒までの遅れはたぶん許容できます。 セッションがあらかじめ定義されるなら、アドレスは、できるだけ早く割り当てられるべきであり、ちょうど以前まで待つべきではありません。
Thaler, et al. Informational [Page 2] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [2ページ]情報のRFC2908MALLOC構造2000年9月
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]で観測されたものなどのネットワーク状態があるときアドレス空間の非常に高い割合の配分を許しそうです。
Thaler, et al. Informational [Page 3] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [3ページ]情報のRFC2908MALLOC構造2000年9月
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などのように不十分でない状況で最終的に高級住宅地スペース用法を達成するのはそれほど重要ではありません、そして、したがって、仕切りは、この構造を使用するホストの中で衝突を全く保証しないように潜在的に使用されるかもしれません。
2.1. Address Dynamics
2.1. アドレス力学
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によって割り当てられます。 静的なアドレスに関する例がそうである、224.0、.1、.1、グローバルな範囲マルチキャストセッション発表において、使用されたNetwork Timeプロトコル[13]と224.2.127.255に使用される。 それがマルチキャストを使用するアプリケーションは目的を独力で進みます。通常、ローカル・サービスとマルチキャストアドレスの間の結合を発表するのに使用できる周知のサービス位置のアドレスを使用することで自分たちを独力で進むべきである以外に、それら自身の静的なマルチキャストアドレスを与えるはずがありません。
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データグラムを受けない、(レベル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.
範囲親類: RFC2365[1]は相対的な課題のためにあらゆる管理範囲の範囲で最も高い256のアドレスを予約します。 相対的な課題は、IANAによって作られていて、あらゆる範囲で有効なオフセットから成ります。 相対アドレスはあらゆる範囲でアドレスを必要とするインフラストラクチャプロトコルのために予約されます、そして、このオフセットは一生懸命アプリケーション、装置、組込み型システムなどにコード化されているかもしれません。 そのような装置には、道がなければなりません。(例えば、MZAP[9]を通して、または、それらが住んでいる範囲のリストを得るMADCAP[4])を通して。
Thaler, et al. Informational [Page 4] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [4ページ]情報のRFC2908MALLOC構造2000年9月
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.
寿命がアドレス配分構造がアドレス用法パターンの周りでアドレスを確実にする方法で組織化されるのを許容するのに必要であるというアドレスにおけるこれらの制限は「集合-可能」です、そして、マルチキャストルーティングは合理的に最適に近いです。 対照的に、静的に割り当てられたアドレスにサブ最適ルーティングを与えるかもしれません。
3. Overview of the Architecture
3. 構造の概観
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スタックの層の番号と異なっていることに注意してください。(番号はデータ・パケットの経路について説明します)。
Thaler, et al. Informational [Page 5] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [5ページ]情報のRFC2908MALLOC構造2000年9月
+--------------------------+ +------------------------+
| | | |
| 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 |
+-------------------------------------------------------------+
+--------------------------+ +------------------------+ | | | | | 他の同輩に| | 他の同輩に| | || // | | || // || | | 接頭語| | 接頭語接頭語| | コーディネータ| |コーディネータのコーディネータ| +------------||------------+ +-------||----//---------+ ||層3|| // +------------||------------------------------||--//-----------+ | 接頭語接頭語| | コーディネータ=======================コーディネータ| | ^ ^ | | +----------------+-------------+ | | | 層2| | | | マース<。---/ | +--->マース| | ^ ^^に対して| | . . マース。| | . .Layer1^.Layer1| | v.Layer1vに対して| | クライアント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つのAプロトコルかメカニズムを層にしてください。 サーバがアドレスを与えるとき、次に、このアドレスが生涯の間の範囲が与えたアドレスのsの中のほかの場所で再利用されないのを保証するのがサーバの責任になります。
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](配分、およびIANAの静的なアドレス課題のためにウェブページにアクセスするHTTP)を含んでいます。
An abstract API for applications to use for dynamic allocation,
independent of the Layer 1 protocol/mechanism in use, is given in
[11].
使用中のLayer1プロトコル/メカニズムの如何にかかわらず、[11]でアプリケーションが動的割当てに使用する抽象的なAPIを与えます。
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のAnイントラドメインプロトコルかメカニズムを層にしてください。 マースには、ユニークさがマースの失敗の向こう側に保存されて、リブートされるのを保証するために、安定貯蔵、または何らかの同等な丈夫さメカニズムがなければなりません。
Thaler, et al. Informational [Page 6] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [6ページ]情報のRFC2908MALLOC構造2000年9月
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は、それらがアドレスを割り当てるかもしれないマルチキャストアドレスの範囲を取得すること(「接頭語コーディネータ」から)にLayer2プロトコル/メカニズムを使用します。
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.
本書では私たちは、特定の範囲のアドレスがLayer2プロトコル/メカニズムによって割り当てられるかもしれないネットワークの行政上見られたマルチキャストできる領域を意味するのに「配分ドメイン」という用語を使用します。
Examples of protocols or mechanisms at this layer include AAP [5],
and manual configuration of MAAS's.
この層のプロトコルかメカニズムに関する例はAAP[5]、およびマースの手動の構成を含んでいます。
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のAn相互ドメインプロトコルかマルチキャストアドレスを割り当てるメカニズムがPrefix Coordinatorsに及びます(生涯で)。 そして、個々のアドレスは上で説明されるように配分ドメインの中にマースのものによってこれらの範囲から割り当てられるかもしれません。
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).
[10](Prefix Coordinatorsはそこの通常人間の管理者である)で説明されるAS番号に従って、この層のプロトコルかメカニズムに関する例はMASC[6](通常、Prefix Coordinatorsはそこの少しも安定貯蔵要件がなければルータです)、および静的割り付けを含んでいます。
Each of the three layers serves slightly different purposes and as such, protocols or mechanisms at each layer may require different design tradeoffs.
それぞれの3つの層がわずかに異なった目的に役立ちます、そして、そういうものとして、各層のプロトコルかメカニズムが意匠相違見返りを必要とするかもしれません。
4. Scoping
4. 見ます。
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.
管理範囲の中にダイナミックなアドレスを割り当てるために、マースはどの範囲が有効であるか、そして、それらのアドレスの範囲と名前が何であるか、そして、動的割当てに、各範囲の中のどのアドレスかサブレンジがマースのそばで有効であるかを学ぶことができなければなりません。
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つのタスク(それぞれの範囲の事実上、範囲を学んで、アドレスの範囲と名前(s))について静的な構成で提供するか、またはダイナミックに、学習するかもしれません。 例えば、マースは単にこの情報を取得する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
(1) 小さい範囲に関して、配分ドメインは管理範囲の中の全体のトポロジーに対応しています。 最終を引いてしたがって、範囲の中のすべてのMAASsが全体のアドレスの範囲を使用するかもしれない、(。
Thaler, et al. Informational [Page 7] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [7ページ]情報のRFC2908MALLOC構造2000年9月
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.
アドレスが範囲相対アドレスとして予約した256) そして、Layer2メカニズム/が配分を調整するために議定書の中で述べる使用。 小さい範囲に関しては、Prefix Coordinatorsはかかわりません。
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).
したがって、小さい範囲に関して、異なった範囲において、有効な「配分ドメイン」領域は異なっているかもしれません。 小さくて、分割できない範囲が大きい範囲に使用されるAllocation Scopeよりさらに大きいか、または小さいかもしれないことに注意してください(以下を見てください)。
(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) 大きい範囲(グローバルな範囲を含んでいる)に関して、範囲の中の地域は単にLayer2メカニズム/プロトコルを使用するのが効率が悪いか、またはそうでなければ、望ましくないことができるほど広大であるかもしれません。 この場合、範囲は複数の配分ドメインにかからなければなりません、そして、配分ドメインの中で見られたアドレス空間を山分けするのにLayer3メカニズム/プロトコルを使用しなければなりません。 したがって、マースがMZAPを通して範囲を知るかもしれませんが、サブレンジを取得しなければならない、Prefix Coordinatorからどれを割り当てるか。
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".
簡単さのために、有効な「配分ドメイン」領域はすべての大きい範囲に同じになるでしょう、すべての大きい範囲に分割される粒状であり。 私たちは、「配分範囲」になるようにこの粒状で管理範囲を定義します。
4.1. Allocation Scope
4.1. 配分範囲
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.
そして、Allocation Scopeが本書では定義された新しい管理範囲である、以下に述べられるように値でIANAによって予約されるように。 これはLayer2プロトコル/メカニズムによって使用される、より大きくて、分割可能な範囲でアドレスのためのアドレス配分を調整する範囲です。
We expect that the Allocation Scope will often coincide with a unicast Autonomous System (AS) boundary.
私たちは、Allocation ScopeがしばしばユニキャストAutonomous System(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を分割されることができます。 ユニキャスト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:
ASが小さ過ぎ、アドレス空間が不十分であるなら、アドレス空間断片化はASがそれ自身の配分ドメインであるなら起こるかもしれません。 ここで、ASは、プロバイダーのマース(もしあれば)とものの間の配分を調整するのに代わりにプロバイダーの配分ドメインの一部として扱われて、Layer2プロトコル/メカニズムを使用できます。 ASがたぶんこの行動を取るはずである、:
Thaler, et al. Informational [Page 8] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [8ページ]情報のRFC2908MALLOC構造2000年9月
o it is connected to a single provider,
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 それは、より大きいことの(言います)256のマルチキャストアドレスよりAS平均的に割り当てられた範囲を必要とします。
4.1.1. The IPv4 Allocation Scope -- 239.251.0.0/16
4.1.1. IPv4配分範囲--239.251 .0.0/、16
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はAllocation Scopeのために予約されることです。 範囲239.248.0 16、.0/239.249.0 16と.0/239.250.0.0/16はこのスペースの拡大に割り当てられないで利用可能なままにされることです。 これらの範囲は.0.0/16スペースがもう239.251に十分にならないまで割り当てられないように残されるべきです。
4.1.2. The IPv6 Allocation Scope -- SCOP 6
4.1.2. IPv6配分範囲--SCOP6
The IPv6 "scop" value 6 is to be used for the Allocation Scope.
IPv6"scop"価値6はAllocation Scopeに使用されることです。
5. Overview of the Allocation Process
5. 割当過程の概観
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.
そして、いったんLayer3配分が大きくて、分割可能な範囲に実行されて、各Prefix Coordinatorが1つ以上の範囲を取得すると、それらの範囲はLayer2メカニズム/プロトコルでPrefix Coordinatorのドメインの中のマースのすべてのものに通り過ぎられます。
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.
ドメインの中のマースのものは、そのドメインへの現在許容できるアドレスとしてこれらの範囲を取って、それらを格納します。 各範囲は、与えられた生涯有効であり(また、Layer3メカニズム/プロトコルで、取得します)、寿命が期限が切れる前に取り消されません。 マースのものは、また、小さい範囲(例えば、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.
Layer2メカニズム/プロトコルを使用して、各マースは、それがそうするどんなアドレスも除くか、またはドメインの中にマースの他のものによって割り当てられるのを確実にします。
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.
クライアントがマルチキャストアドレスを必要とすると、それは、最初に、意図しているセッションの範囲が何であるべきであるかを決めて、その範囲の中にアドレスを割り当てることができるマースの場所を見つける必要があります。
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つを選択するのを許容するでしょう。
Thaler, et al. Informational [Page 9] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [9ページ]情報のRFC2908MALLOC構造2000年9月
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.
さまざまな方法でマースの場所を見つけることができます、手動の構成を含んでいて、SLP[12]など、またはLayer1プロトコル自体によって提供されたメカニズムでサービス位置のプロトコルを使用して。 例えば、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.
一度、クライアントは、範囲を選んで、マースの場所を見つけたことがあって、次に、それは、マースからのその範囲のアドレスが場所を見つけたよう要求します。 また、要求と共に、それはそれが望んでいる配分の生涯、許容できる範囲を通り過ぎます。 例えば、使用中のLayer1プロトコルがMADCAPであるなら、クライアントは、MADCAP REQUESTメッセージをマースに送って、割り当てられた情報を含む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.
クライアントから要求を受け取ると、次に、マースは指定された範囲への範囲の未使用のアドレスを選びます、クライアントによって指定された許容できる範囲を満たして、実際の範囲の生涯中に、ある生涯で。
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.
マースは、そのようなアドレスが他のMAASsによって割り当てられるどんなアドレスにも衝突しないのを保証するのにLayer2メカニズム/プロトコルを使用します。 例えば、Layer2が非重なっている範囲の手動の構成を使用するなら、これは地方のマースで構成された範囲を固く守るのから単に成ります。 他方では、AAPが、より少ないアドレス空間断片化を提供するのにLayer2で使用されるなら、マースは、AAPを使用することで提案された配分のドメイン全体で広告を出します。 短い時間間隔以内にAAPが要求する衝突でないのを受け取るなら、Layer1プロトコル/メカニズムでアドレスをクライアントに返します。 衝突クレームがマースによって受け取られるなら、それは、異なったアドレスを選んで、再試行します。 また、AAPは各マースにそれが衝突を検出するのを待つ必要はないアドレスの小さい「プール」をあらかじめ予約させます。
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.
ドメインが利用可能なマルチキャストアドレスを使い果たし始めるなら、そのドメインのPrefix Coordinatorは、より多くのスペースを取得するのにLayer3プロトコル/メカニズムを使用します。
6. Security Considerations
6. セキュリティ問題
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
ここに説明された構造は、アプリケーションがただそれを割り当てないでマルチキャストアドレスを発信するか、または接合するのを防ぎません(ユニキャストアドレスに、ちょうど同じくらいが今日本当であるように)。 しかしながら、「非-割り当て」られたアドレスのためのデータがネットワークによって送られるという保証が全くありません。 それらに送付先アドレスが割り当てられたかどうかチェックする何らかの方法があるなら、すなわち、ルータは「非-割り当て」られたアドレスのためのデータを落とすかもしれません。 例えば、ドメインの境界ルータであるなら、「非-割り当て」られて、2が/メカニズムについて議定書の中で述べて、割り当てられたアドレス、当時のデータのセットをキャッシュするLayerに参加してください。
Thaler, et al. Informational [Page 10] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [10ページ]情報のRFC2908MALLOC構造2000年9月
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.
空の送信するインタフェースリストでマルチキャスト推進状態を創設する、そして/または、それらのグループのために木の枝を剪定し返しながら、そのドメインによって割り当てられた範囲のアドレスに立ち寄ることができます。
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.
したがって、この構造の層を実行するプロトコル/メカニズムは安全なファッションで配備可能であるはずです。 例えば、方針制限で認証を支持するべきであり、別のパーティーの配分をリリースするか、またはだれか権限がない人が変更するのを許容するべきではありません。
7. Acknowledgments
7. 承認
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共同体はこの仕事に関する動機を提供しました。
8. References
8. 参照
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[1] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、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] ハンドレーと、「マルチキャストセッションディレクトリとアドレス配分」(「スケーラブルなマルチメディア会議システム」、ロンドン大学、1997の権利を与えられた博士号Thesisの第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] 「Mboneパフォーマンスの分析」、博士号Thesisの第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.シャー、「マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)」、RFC2730、1999年12月。
[5] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol
(AAP)", Work in Progress.
[5] 「マルチキャストアドレス配分プロトコル(AAP)」というハンドレー、M.、およびS.ハンナは進行中で働いています。
[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.とハンドレーとM.とクマーとS.とラドスラーボフとP.とD.ターレル、「マルチキャストアドレスセットクレーム(MASC)プロトコル」、RFC2909、2000年9月。
Thaler, et al. Informational [Page 11] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [11ページ]情報のRFC2908MALLOC構造2000年9月
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[7] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[8]RekhterとY.と1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[9] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone
Announcement Protocol (MZAP)", RFC 2776, February 2000.
[9] ハンドレーとM.とターレルとD.とR.カーモード、「マルチキャスト範囲ゾーン発表プロトコル(MZAP)」、RFC2776 2000年2月。
[10] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770,
February 2000.
[10] マイヤーとD.とP.Lothberg、「233/8インチ、RFCに2770、2000年2月を記述するGLOP。」
[11] Finlayson, R., "Abstract API for Multicast Address Allocation",
RFC 2771, February 2000.
[11] フィンリースン、R.、「マルチキャストアドレス配分のための抽象的なAPI」、RFC2771、2000年2月。
[12] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[12] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[13] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[13] 工場、D.、「ネットワーク時間は仕様、実現、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
9. Authors' Addresses
9. 作者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
デーヴターレルマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン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
バークレー、Suite600カリフォルニア ICSI1947センター通り、94704でのインターネット調査のためのマークハンドレーAT&Tセンター
EMail: mjh@aciri.org
メール: mjh@aciri.org
Deborah Estrin Computer Science Dept/ISI University of Southern California Los Angeles, CA 90089
南カリフォルニアロサンゼルス、カリフォルニア 90089人のデボラEstrinコンピュータサイエンス部/ISI大学
EMail: estrin@usc.edu
メール: estrin@usc.edu
Thaler, et al. Informational [Page 12] RFC 2908 MALLOC Architecture September 2000
ターレル、他 [12ページ]情報のRFC2908MALLOC構造2000年9月
10. Full Copyright Statement
10. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Thaler, et al. Informational [Page 13]
ターレル、他 情報[13ページ]
一覧
スポンサーリンク
