[要約] RFC 3180は、GLOPアドレッシングが233/8の範囲で使用されることを定義しています。このRFCの目的は、グローバルなアドレス空間を効果的に利用するために、GLOPアドレッシングの使用方法を提案することです。
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
233/8でのGLOPアドレス指定
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document defines the policy for the use of 233/8 for statically assigned multicast addresses.
このドキュメントは、静的に割り当てられたマルチキャストアドレスに233/8を使用するためのポリシーを定義しています。
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]に従って223/8を割り当てました。このドキュメントは、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]に従って223/8を割り当てました。RFC 2770は、RFC 1797に記載されている方法と同様の方法で、233/8の中央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を考慮してください。バイナリで書かれ、0Sでパディングされた左に、0001011000011110を取得します。高次のオクテットをアドレスの2番目のオクテットにマッピングし、3番目のオクテットまでのローオーダーオクテットをマッピングします。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 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]としてプライベートにマッピングされる233/8の一部は、IRRS [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.
このアプローチは、2オクテットの数としてのみ機能することに注意することが重要です。特に、数としての拡張スキームでは機能しません。
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は、この目的のために233/8を割り当てました。
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に記載されているのと同じ割り当て（ベース）を使用しているというピーターロスバーグの考えから生まれました。ランディブッシュとマークハンドリーは多くの洞察に満ちたコメントを提供し、ピートとナタリーホワイティングはこの文書の読みやすさに大きく貢献しました。
[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] 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月。
[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月。
[RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000.
[RFC2770] Meyer、D。およびP. Lothberg、「233/8でのGlopアドレス指定」、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.、Govindan、R.、Handley、M.、Kumar、S.およびD. Thaler、「マルチキャストアドレスセットクレーム（MASC）プロトコル」、RFC 2909、2000年9月。
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。and E. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[RFC3138] Meyer、D。、「233/8の拡張割り当て」、RFC 3138、2001年6月。
David Meyer Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196
David Meyer Sprint Varesa0104 12502サンライズバレードライブレストンVA、20196
EMail: dmm@sprint.net
Peter Lothberg Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196
ピーターロスバーグスプリントvaresa0104 12502サンライズバレードライブレストンVA、20196
EMail: roll@sprint.net
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。