[要約] RFC 2770は、IPv4アドレス空間の一部である233/8のGLOPアドレッシングについてのガイドラインです。このRFCの目的は、グローバルなマルチキャストアドレスの割り当てと使用を効率化することです。
Network Working Group D. Meyer
Request for Comments: 2770 Cisco Systems
Category: Experimental P. Lothberg
Sprint
February 2000
GLOP Addressing in 233/8
233/8でのGLOPアドレス指定
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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アドレススペースの実験的に割り当てられたサブセットとして233/8を使用して、クラス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は233/8を割り当てました。残りの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を考慮してください。バイナリで書かれ、0Sでパッドで埋められている左に、0001011000011110を取得します。高次のオクテットをアドレスの2番目のオクテットにマッピングし、低次のオクテットを3番目のオクテットにマッピングすると、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.
上記のように、ここで提案されている割り当ては、次のように変更されたRFC 1797（ケース1）割り当てスキームに従います。高次のオクテットには値233があり、次の16ビットは以前に割り当てられた自律システム番号（AS）です。ネットワークレジストリによって、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]を参照）。ここでの理由は、233/8から取得した静的に割り当てられたアドレスが、静的アドレス指定が必要なアプリケーションに十分である可能性があり、その他のアドレス指定は、[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は、実験的割り当てに233/8を割り当てました。この割り当ては、割り当てが行われてから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で説明されているのと同じ割り当て（ベース）を使用するというピーターロスバーグのアイデアから生まれました。ランディブッシュとマークハンドリーは、多くの洞察に満ちたコメントを提供しました。
[RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[RFC2730] Hanna、S.、Patel、B。、およびM. Shah、「マルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）」、RFC 2730、1999年12月。
[MASC] D. Estrin, et al., "The Multicast Address-Set Claim (MASC) Protocol", Work in Progress.
[MASC] D. Estrin、et al。、「マルチキャストアドレスセットクレーム（MASC）プロトコル」、進行中の作業。
[MSDP] D. Farinacci et al., "Multicast Source Discovery Protocol (MSDP)", Work in Progress.
[MSDP] D. Farinacci et al。、「Multicast Source Discovery Protocol（MSDP）」、Work in Progress。
[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] Meyer、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.、O'Dell、M。、およびS. Deering、「IPv6 Agregatable Global Unicastアドレス形式」、RFC 2374、1998年7月。
[SAP] Handley, M., "SAP: Session Announcement Protocol", Work in Progress.
[SAP] Handley、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
David Meyer Cisco Systems、Inc。170 W. Tasman Drive San Jose、CA 95134-1706米国
EMail: dmm@cisco.com
Peter Lothberg Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196
ピーターロスバーグスプリントvaresa0104 12502サンライズバレードライブレストンVA、20196
EMail: roll@sprint.net
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エディター機能の資金は現在、インターネット協会によって提供されています。