Network Working Group D. Meyer
Request for Comments: 2770 Cisco Systems
Category: Experimental P. Lothberg
Sprint
February 2000
GLOP Addressing in 233/8
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]).
これは、クラスDアドレス空間の実験静的に割り当てられたサブセットとして8分の233を使用して、クラスDアドレス空間の使用のための実験的ポリシーを記述する。この新しい実験割り当ては[IANA]に記載されたものに加えて、（例えば、[RFC2365]）。
This memo is a product of the Multicast Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to <mboned@ns.uoregon.edu> or the authors.
このメモはインターネットエンジニアリングタスクフォースの運用と管理領域におけるマルチキャスト展開ワーキンググループ（MBONED）の製品です。 <mboned@ns.uoregon.edu>や作者へのコメントを提出してください。
Multicast addresses have traditionally been allocated by a dynamic mechanism such as SDR [SAP]. However, many current multicast deployment models are not amenable to dynamic allocation. For example, many content aggregators require group addresses which are fixed on a time scale which is not amenable to allocation by a mechanism such as described in [SAP]. Perhaps more seriously, since there isn't general consensus by providers, content aggregators, or application writers as to the allocation mechanism, the Internet is left without a coherent multicast address allocation scheme.
マルチキャストアドレスは、伝統的に、このようなSDR [SAP]などの動的メカニズムによって割り当てられています。しかし、多くの現在のマルチキャスト展開モデルは、動的割り当てに従順ではありません。例えば、多くのコンテンツアグリゲータは、[SAP]に記載されているような機構により、割り当てに従順でない時間スケール上に固定されているグループアドレスを必要とします。配分メカニズムのようプロバイダー、コンテンツアグリゲータ、またはアプリケーションの作家による一般的なコンセンサスがないので、おそらくもっと真剣に、インターネットは、コヒーレントマルチキャストアドレス割り当て方式ずに残っています。
The MALLOC working group is looking at a specific strategy for global multicast address allocation [MADCAP, MASC]. This experiment will proceed in parallel. MADCAP may be employed within AS's, if so desired.
MALLOCワーキンググループは、グローバルマルチキャストアドレスの割り当て[MADCAP、MASC]のための具体的な戦略を見ています。この実験は、並行して進めてまいります。必要に応じてMADCAPは、ASの内で使用することができます。
This document proposes an experimental method of statically allocating multicast addresses with global scope. This experiment will last for a period of one year, but may be extended as described in section 6.
この文書では、静的にグローバルスコープとマルチキャストアドレスを割り当てるの実験的方法を提案しています。この実験は、1年間持続しますが、セクション6で説明したように延長することができます。
For purposes of the experiment described here, the IANA has allocated 233/8. The remaining 24 bits will be administered in a manner similar to that described in RFC 1797:
ここに記載した実験の目的のために、IANAは、8分の233を割り当てています。残りの24ビットは、RFC 1797に記載の方法と類似の方法で投与されるであろう。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 233 | 16 bits AS | local bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Consider, for example, AS 5662. Written in binary, left padded with 0s, we get 0001011000011110. Mapping the high order octet to the second octet of the address, and the low order octet to the third octet, we get 233.22.30/24.
例えば、バイナリで5662.書かれた、0でパディング左、考えてみましょう、我々は3番目のオクテットにアドレスの第2オクテット、および低次のオクテットに上位オクテットのマッピング0001011000011110.を取得し、我々は/ 233.22.30取得します24。
As mentioned above, the allocation proposed here follows the RFC 1797 (case 1) allocation scheme, modified as follows: the high order octet has the value 233, and the next 16 bits are a previously assigned Autonomous System number (AS), as registered by a network registry and listed in the RWhois database system. This allows a single /24 per AS.
高次のオクテットは、値233を有しており、登録された次の16ビットは、以前に割り当てられた自律システム番号（AS）である。上述したように、ここで提案された割り当ては次のように変更、RFC 1797（ケース1）割り当て方式に従いますネットワークレジストリによるとRWhoisデータベースシステムに記載されています。これは、ASごとに単一/ 24ことができます。
As was the case with RFC 1797, using the AS number in this way allows the experiment to get underway quickly in that it automatically allocates some addresses to each service provider and does not require a registration step.
RFC 1797の場合と同様に、このようにAS番号を使用することは、自動的に各サービスプロバイダにいくつかのアドレスを割り当て、登録ステップを必要としないという点で実験が急速に進行取得することができます。
The address space mapped to the private AS space [RFC1930] is reserved for future allocation.
スペース[RFC1930]とプライベートにマッピングされたアドレス空間は、将来の割り当てのために予約されています。
It may not be necessary to transition from the address allocation scheme described here to a more dynamic approach (see, e.g., [MASC]). The reasoning here is that the statically assigned addresses taken from 233/8 may be sufficient for those applications which must have static addressing, and any other addressing can come from either a dynamic mechanism such as [MASC], the administratively scoped address space [RFC2365], or the Single-source address space [SS].
より動的なアプローチをここで説明したアドレス割当方式から移行する必要はないかもしれない（参照、例えば、[MASC]）。ここで推論は8分の233から取られた静的に割り当てられたアドレスは静的アドレスを持つ必要があり、これらの用途のために十分であってもよく、アドレッシング他は、[MASC]、管理スコープアドレス空間[RFC2365として動的機構のいずれかから来ることができるということです]、またはシングルソース・アドレス・スペース[SS]。
The approach described here may have the effect of reduced exposure to denial of space attacks based on dynamic allocation. Further, since dynamic assignment does not cross domain boundaries, well known intra-domain security techniques can be applied.
ここで説明するアプローチは、動的な割り当てに基づいて、空間妨害攻撃に対する低減曝露の効果を有していてもよいです。さらに、動的な割り当ては、ドメイン内のセキュリティ技術を適用することができる周知のクロスドメインの境界をしないからです。
IANA has allocated 233/8 for experimental assignments. This assignment should timeout one year after the assignment is made. The assignment may be renewed at that time. It should be noted that the experiment described here is in the same spirit the experiment described in [RFC1797].
IANAは、実験的な割り当てのために8分の233を割り当てています。割り当てが行われた後にこの割り当ては、1年をタイムアウトする必要があります。割り当ては、その時点で更新することができます。なお、ここで説明する実験は、[RFC1797]に記載した実験は、同じ精神であることに留意されたいです。
This idea originated with Peter Lothberg's idea that we use the same allocation (AS based) as described in RFC 1797 in the class D address space. Randy Bush and Mark Handley contributed many insightful comments.
クラスDアドレス空間でRFC 1797で説明したように、このアイデアは、我々は同じ割り当てを使用ピーター・ロスバーグのアイデアを起源（ASベース）。ランディブッシュとマーク・ハンドリーは、多くの洞察に満ちたコメントを貢献しました。
[RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[RFC2730]ハンナ、S.、パテル、B.及びM.シャー、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、1999年12月。
[MASC] D. Estrin, et al., "The Multicast Address-Set Claim (MASC) Protocol", Work in Progress.
【MASC] D. Estrin、ら、 "マルチキャストアドレスセットクレーム（MASC）プロトコル"、ProgressのWork。
[MSDP] D. Farinacci et al., "Multicast Source Discovery Protocol (MSDP)", Work in Progress.
[MSDP] D.ファリナッチら、 "マルチキャストソース発見プロトコル（MSDP）"、ProgressのWork。
[IANA] www.isi.edu/in-notes/iana/assignments/multicast-addresses
[IANA] www.isi.edu/in-notes/iana/assignments/multicast-addresses
[RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April 1995.
[RFC1797] IANA、 "クラスAサブネット実験"、RFC 1797、1995年4月。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
[RFC1930]ホーキンソン、J.およびT.ベイツ、 "作成、選択、および自律システム（AS）の登録のためのガイドライン"、RFC 1930、1996年3月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[RFC2365]マイヤー、D.、 "管理スコープのIPマルチキャスト"、RFC 2365、1998年7月。
[RFC2374] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[RFC2374] HindenとR.、オデル、M.とS.デアリング、 "IPv6の集約可能グローバルユニキャストアドレス形式"、RFC 2374、1998年7月。
[SAP] Handley, M., "SAP: Session Announcement Protocol", Work in Progress.
[SAP]ハンドリー、M.、 "SAP：セッションアナウンスメントプロトコル" が進行中で働いています。
[SS] www.isi.edu/in-notes/iana/assignments/single-source-multicast
[SS] www.isi.edu/in-notes/iana/assignments/single-source-multicast
David Meyer Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 United States
デビッド・マイヤーシスコシステムズ社170 W.タスマン・ドライブサンノゼ、CA 95134-1706米国
EMail: dmm@cisco.com
メールアドレス：dmm@cisco.com
Peter Lothberg Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196
ピーター・ロスバーグスプリントVARESA0104 12502日の出バレードライブレストンVA、20196
EMail: roll@sprint.net
メールアドレス：roll@sprint.net
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機能のための基金は現在、インターネット協会によって提供されます。