Network Working Group D. Meyer
Request for Comments: 3180 P. Lothberg
Obsoletes: 2770 Sprint
BCP: 53 September 2001
Category: Best Current Practice
GLOP Addressing in 233/8
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document defines the policy for the use of 233/8 for statically assigned multicast addresses.
この文書では、静的に割り当てられたマルチキャストアドレスのための8分の233を使用するためのポリシーを定義します。
It is envisioned that the primary use of this space will be many-to-many applications. This allocation is in addition to those described on [IANA] (e.g., [RFC2365]). The IANA has allocated 223/8 as per RFC 2770 [RFC2770]. This document obsoletes RFC 2770.
このスペースの主な用途は、多対多のアプリケーションになることが想定されます。この割り当ては、[IANA]に記載されたものに加えて、（例えば、[RFC2365]）。 IANAは、RFC 2770 [RFC2770]に従って8分の223を割り当てました。この文書はRFC 2770を廃止します。
Multicast addresses have traditionally been allocated by a dynamic mechanism such as SDR [RFC2974]. However, many current multicast deployment models are not amenable to dynamic allocation. For example, many content aggregators require group addresses that are fixed on a time scale that is not amenable to allocation by a mechanism such as described in [RFC2974]. Perhaps more seriously, since there is not 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 [RFC2974]などの動的な機構によって割り当てられています。しかし、多くの現在のマルチキャスト展開モデルは、動的割り当てに従順ではありません。例えば、多くのコンテンツアグリゲータは、[RFC2974]に記載されているような機構によって割り当てに適していない時間スケール上に固定されているグループアドレスを必要とします。配分メカニズムのようプロバイダー、コンテンツアグリゲータ、またはアプリケーションの作家による一般的なコンセンサスがないので、おそらくもっと真剣に、インターネットは、コヒーレントマルチキャストアドレス割り当て方式ずに残っています。
The MALLOC working group has created a specific strategy for global multicast address allocation [RFC2730, RFC2909]. However, this approach has not been widely implemented or deployed. This document proposes a solution for a subset of the problem, namely, those cases not covered by Source Specific Multicast.
MALLOCワーキンググループは、グローバルなマルチキャストアドレス割り当て[RFC2730、RFC2909]のための特定の戦略を作成しました。しかし、このアプローチは広く実装または配備されていません。この文書では、すなわち、そのような場合は、ソース固有マルチキャストでカバーされていない問題のサブセットのためのソリューションを提案しています。
The IANA has allocated 223/8 as per RFC 2770 [RFC2770]. RFC 2770 describes the administration of the middle two octets of 233/8 in a manner similar to that described in RFC 1797:
IANAは、RFC 2770 [RFC2770]に従って8分の223を割り当てました。 RFC 2770は、RFC 1797に記載されたものと同様の方法で8分の233の真ん中の2つのオクテットの投与を記載しています。
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 automatic assignment of a single /24 to each service provider and does not require an additional registration step.
RFC 1797の場合と同様に、このようにしてAS番号を使用する各サービスプロバイダへの単一/ 24の自動割り当てを可能にし、追加登録ステップを必要としません。
The part of 233/8 that is mapped to the private AS space [RFC1930] is assigned to the IRRs [RFC3138].
スペース[RFC1930]とプライベートにマッピングされている8分の233の一部はのIRR [RFC3138]に割り当てられています。
It is important to note that this approach will work only for two octet AS numbers. In particular, it does not work for any AS number extension scheme.
このアプローチはAS番号2つのオクテットのためにのみ動作することに注意することが重要です。特に、それは、任意のAS番号拡張スキームのために動作しません。
The approach described here may have the effect of reduced exposure to denial-of-service attacks based on dynamic allocation. Further, since dynamic assignment does not cross domain boundaries, well-known intra-domain security techniques can be applied.
ここで説明するアプローチは、動的な割り当てに基づいてサービス拒否攻撃に減少曝露の効果を有していてもよいです。動的割り当てがドメイン境界を横切らないので、よく知られているドメイン内のセキュリティ技術を適用することができます。
The IANA has assigned 233/8 for this purpose.
IANAは、この目的のために8分の233が割り当てられています。
This proposal originated with Peter Lothberg's idea that we use the same allocation (AS based) as described in RFC 1797. Randy Bush and Mark Handley contributed many insightful comments, and Pete and Natalie Whiting contributed greatly to the readability of this document.
この提案は、RFC 1797年ランディブッシュとマーク・ハンドリーで説明したように、我々は同じ配分を（ベースAS）を使用ピーター・ロスバーグのアイデアを発信し、多くの洞察に満ちたコメントを拠出し、ピートとナタリー・ホワイティングは、この文書の読みやすさに大きく貢献しました。
[IANA] http://www.iana.org/numbers.html
[IANA] http://www.iana.org/numbers.html
[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月。
[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月。
[RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000.
[RFC2770]マイヤー、D.とP. Lothberg、 "GLOPは8分の233でアドレス指定"、RFC 2770、2000年2月。
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., Kumar, S. and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000.
[RFC2909] Radoslavov、P.、Estrin、D.、ゴヴィンダン、R.、ハンドレー、M.、クマー、S.およびD.ターレル、 "マルチキャストアドレスセットクレーム（MASC）プロトコル"、RFC 2909、2000年9月。
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]ハンドリー、M.、パーキンス、C.とE.ウィーラン、 "セッションアナウンスメントプロトコル"、RFC 2974、2000年10月。
[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[RFC3138]マイヤー、D.、 "8分の233で拡張割り当て"、RFC 3138、2001年6月。
David Meyer Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196
デビッド・マイヤースプリントVARESA0104 12502日の出バレードライブレストンVA、20196
EMail: dmm@sprint.net
メールアドレス：dmm@sprint.net
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。