Network Working Group D. Meyer
Request for Comments: 2770 Cisco Systems
Category: Experimental P. Lothberg
Sprint
February 2000
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.
版权所有（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]).
这描述了使用233/8作为D类地址空间的实验静态分配子集使用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]中所述的机制进行分配。也许更严重的是，由于提供商、内容聚合器或应用程序编写者对分配机制没有达成普遍共识，因此Internet没有一致的多播地址分配方案。
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]。这个实验将并行进行。如果需要，可在AS内使用MADCAP。
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.
本文提出了一种在全局范围内静态分配多播地址的实验方法。该实验将持续一年，但可按第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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 the experiment to get underway quickly in that it automatically allocates some addresses to each service provider and does not require a registration step.
与RFC1797的情况一样，以这种方式使用As编号可以让实验快速进行，因为它自动为每个服务提供商分配一些地址，并且不需要注册步骤。
The address space mapped to the private AS space [RFC1930] is reserved for future allocation.
映射到专用AS空间[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用于实验作业。此分配应在分配后一年超时。该转让可在当时续签。应该注意的是，这里描述的实验与[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.
这个想法源于Peter Lothberg的想法，即我们在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）”，RFC2730，1999年12月。
[MASC] D. Estrin, et al., "The Multicast Address-Set Claim (MASC) Protocol", Work in Progress.
[MASC]D.Estrin等人，“多播地址集声明（MASC）协议”，正在进行中。
[MSDP] D. Farinacci et al., "Multicast Source Discovery Protocol (MSDP)", Work in Progress.
[MSDP]D.Farinaci等人，“多播源发现协议（MSDP）”，正在进行中。
[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类子网实验”，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月。
[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号，邮编95134-1706
EMail: dmm@cisco.com
EMail: dmm@cisco.com
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 (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编辑功能的资金目前由互联网协会提供。