Network Working Group D. Meyer
Request for Comments: 3180 P. Lothberg
Obsoletes: 2770 Sprint
BCP: 53 September 2001
Category: Best Current Practice
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.
版权所有（C）互联网协会（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]中所述的机制进行分配。也许更严重的是，由于提供商、内容聚合器或应用程序编写者对分配机制没有达成普遍共识，因此Internet没有一致的多播地址分配方案。
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中间两个八位字节的管理：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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，得到000101100001110。将高阶八位元映射到地址的第二个八位元，将低阶八位元映射到第三个八位元，我们得到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数据库系统中列出。这允许一个/24的AS。
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].
233/8中映射到专用AS空间[RFC1930]的部分分配给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号码扩展方案。
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.
该提案源于Peter Lothberg的想法，即我们使用RFC 1797中描述的相同分配（基于）。兰迪·布什（Randy Bush）和马克·汉德利（Mark Handley）发表了许多有见地的评论，皮特（Pete）和娜塔莉·惠汀（Natalie Whiting）对本文件的可读性做出了巨大贡献。
[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类子网实验”，RFC1797，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可聚合全球单播地址格式”，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）”，RFC2730，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 27702000年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 29092000年9月。
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.和E.Whelan，“会话公告协议”，RFC 29742000年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弗吉尼亚州莱斯顿日出谷大道，20196
EMail: dmm@sprint.net
EMail: dmm@sprint.net
Peter Lothberg Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196
彼得·洛斯伯格斯普林特瓦雷萨0104 12502弗吉尼亚州莱斯顿日出谷大道，20196
EMail: roll@sprint.net
EMail: 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编辑功能的资金目前由互联网协会提供。