Network Working Group                                         D. Thaler
Request for Comments: 2908                                    Microsoft
Category: Informational                                      M. Handley
                                                              D. Estrin
                                                         September 2000
Network Working Group                                         D. Thaler
Request for Comments: 2908                                    Microsoft
Category: Informational                                      M. Handley
                                                              D. Estrin
                                                         September 2000

The Internet Multicast Address Allocation Architecture


Status of this Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2000). All Rights Reserved.




This document proposes a multicast address allocation architecture (MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server-server coordination mechanism, and an inter-domain mechanism.


Table of Contents


   1: Introduction ................................................  2
   2: Requirements ................................................  2
   3.1: Address Dynamics ..........................................  4
   3: Overview of the Architecture ................................  5
   4: Scoping .....................................................  7
   4.1: Allocation Scope ..........................................  8
   4.1.1: The IPv4 Allocation Scope -- .............  9
   4.1.2: The IPv6 Allocation Scope -- SCOP 6 .....................  9
   5: Overview of the Allocation Process ..........................  9
   6: Security Considerations ..................................... 10
   7: Acknowledgments ............................................. 11
   8: References .................................................. 11
   9: Authors' Addresses .......................................... 12
   10: Full Copyright Statement ................................... 13
   1: Introduction ................................................  2
   2: Requirements ................................................  2
   3.1: Address Dynamics ..........................................  4
   3: Overview of the Architecture ................................  5
   4: Scoping .....................................................  7
   4.1: Allocation Scope ..........................................  8
   4.1.1: The IPv4 Allocation Scope -- .............  9
   4.1.2: The IPv6 Allocation Scope -- SCOP 6 .....................  9
   5: Overview of the Allocation Process ..........................  9
   6: Security Considerations ..................................... 10
   7: Acknowledgments ............................................. 11
   8: References .................................................. 11
   9: Authors' Addresses .......................................... 12
   10: Full Copyright Statement ................................... 13
1. Introduction
1. 介绍

This document proposes a multicast address allocation architecture (MALLOC) for the Internet, and is intended to be generic enough to apply to both IPv4 and IPv6 environments.


As with unicast addresses, the usage of any given multicast address is limited in two dimensions:


Lifetime: An address has a start time and a (possibly infinite) end time, between which it is valid.


Scope: An address is valid over a specific area of the network. For example, it may be globally valid and unique, or it may be a private address which is valid only within a local area.


This architecture assumes that the primary scoping mechanism in use is administrative scoping, as described in RFC 2365 [1]. While solutions that work for TTL scoping are possible, they introduce significant additional complication for address allocation [2]. Moreover, TTL scoping is a poor solution for multicast scope control, and our assumption is that usage of TTL scoping will decline before this architecture is widely used.

如RFC 2365[1]中所述,该体系结构假设使用的主要作用域机制是管理作用域。虽然TTL作用域的解决方案是可能的,但它们为地址分配带来了显著的额外复杂性[2]。此外,TTL作用域控制对于多播作用域控制来说是一个糟糕的解决方案,我们的假设是,在这种体系结构被广泛使用之前,TTL作用域的使用将会下降。

2. Requirements
2. 要求

From a design point of view, the important properties of multicast allocation mechanisms are robustness, timeliness, low probability of clashing allocations, and good address space utilization in situations where space is scare. Where this interacts with multicast routing, it is desirable for multicast addresses to be allocated in a manner that aids aggregation of routing state.


o Robustness/Availability

o 健壮性/可用性

The robustness requirement is that an application requiring the allocation of an address should always be able to obtain one, even in the presence of other network failures.


o Timeliness

o 及时性

From a timeliness point of view, a short delay of up to a few seconds is probably acceptable before the client is given an address with reasonable confidence in its uniqueness. If the session is defined in advance, the address should be allocated as soon as possible, and should not wait until just before the


session starts. It is in some cases acceptable to change the multicast addresses used by the session up until the time when the session actually starts, but this should only be done when it averts a significant problem such as an address clash that was discovered after initial session definition.


o Low Probability of Clashes

o 冲突概率低

A multicast address allocation scheme should always be able to allocate an address that can be guaranteed not to clash with that of another session. A top-down partitioning of the address space would be required to completely guarantee that no clashes would occur.


o Address Space Packing in Scarcity Situations

o 解决稀缺情况下的空间打包问题

In situations where address space is scarce, simply partitioning the address space would result in significant fragmentation of the address space. This is because one would need enough spare space in each address space partition to give a reasonable degree of assurance that addresses could still be allocated for a significant time in the event of a network partition. In addition, providing backup allocation servers in such a hierarchy, so that fail-over (including partitioning of a server and its backup from each other) does not cause collisions would add further to the address space fragmentation.


Since guaranteeing no clashes in a robust manner requires partitioning the address space, providing a hard guarantee leads to inefficient address space usage. Hence, when address space is scarce, it is difficult to achieve constant availability and timeliness, guarantee no clashes, and achieve good address space usage. As a result, we must prioritize these properties. We believe that, when address space is scarce, achieving good address space packing and constant availability are more important than guaranteeing that address clashes never occur. What we aim for in these situations is a very high probability that an address clash does not occur, but we accept that there is a finite probability of this happening. Should a clash occur (or should an application start using an address it did not allocate, which may also lead to a clash), either the clash can be detected and addresses changed, or hosts receiving additional traffic can prune that traffic using source-specific prunes available in IGMP version 3, and so we do not believe that this is a disastrous situation.


In summary, tolerating the possibility of clashes is likely to allow allocation of a very high proportion of the address space in the presence of network conditions such as those observed in [3].


We believe that we can get good packing and good availability with good collision avoidance, while we would have to compromise packing and availability significantly to avoid all collisions.


Finally, in situations where address space is not scarce, such as with IPv6, achieving good address space usage is less important, and hence partitioning may potentially be used to guarantee no collisions among hosts that use this architecture.


2.1. Address Dynamics
2.1. 地址动态

Multicast addresses may be allocated in any of three ways:


Static: Statically allocated addresses are allocated by IANA for specific protocols that require well-known addresses to work. Examples of static addresses are which is used for the Network Time Protocol [13] and which is used for global scope multicast session announcements. Applications that use multicast for bootstrap purposes should not normally be given their own static multicast address, but should bootstrap themselves using a well-known service location address which can be used to announce the binding between local services and multicast addresses.


Static addresses typically have a permanent lifetime, and a scope defined by the scope range in which they reside. As such, a static address is valid everywhere (although the set of receivers may be different depending on location), and may be hard-coded into applications, devices, embedded systems, etc. Static addresses are also useful for devices which support sending but not receiving multicast IP datagrams (Level 1 conformance as specified in RFC 1112 [7]), or even are incapable of receiving any data at all, such as a wireless broadcasting device.

静态地址通常有一个永久的生存期,其作用域由它们所在的作用域范围定义。因此,静态地址在任何地方都有效(尽管接收器集可能因位置不同而不同),并且可以硬编码到应用程序、设备、嵌入式系统等中。静态地址也可用于支持发送但不接收多播IP数据报的设备(RFC 1112[7]中规定的1级一致性),甚至无法接收任何数据,如无线广播设备。

Scope-relative: RFC 2365 [1] reserves the highest 256 addresses in every administrative scope range for relative assignments. Relative assignments are made by IANA and consist of an offset which is valid in every scope. Relative addresses are reserved for infrastructure protocols which require an address in every scope, and this offset may be hard-coded into applications, devices, embedded systems, etc. Such devices must have a way (e.g. via MZAP [9] or via MADCAP [4]) to obtain the list of scopes in which they reside.

作用域相对:RFC 2365[1]为相对分配保留每个管理作用域范围中最高的256个地址。相对分配由IANA进行,包括在每个范围内有效的偏移量。相对地址保留给在每个作用域中都需要地址的基础设施协议,该偏移可以硬编码到应用程序、设备、嵌入式系统等中。此类设备必须有一种方法(例如,通过MZAP[9]或通过MADCAP[4])来获取其驻留的作用域列表。

The offsets assigned typically have a permanent lifetime, and are valid in every scope and location. Hence, the scope-relative address in a given scope range has a lifetime equal to that of the scope range in which it falls.


Dynamic: For most purposes, the correct way to use multicast is to obtain a dynamic multicast address. These addresses are provided on demand and have a specific lifetime. An application should request an address only for as long as it expects to need the address. Under some circumstances, an address will be granted for a period of time that is less than the time that was requested. This will occur rarely if the request is for a reasonable amount of time. Applications should be prepared to cope with this when it occurs.


At any time during the lifetime of an existing address, applications may also request an extension of the lifetime, and such extensions will be granted when possible. When the address extension is not granted, the application is expected to request a new address to take over from the old address when it expires, and to be able to cope with this situation gracefully. As with unicast addresses, no guarantee of reachability of an address is provided by the network once the lifetime expires.


These restrictions on address lifetime are necessary to allow the address allocation architecture to be organized around address usage patterns in a manner that ensures addresses are aggregatable and multicast routing is reasonably close to optimal. In contrast, statically allocated addresses may be given sub-optimal routing.


3. Overview of the Architecture
3. 架构概述

The architecture is modular so that each layer may be used, upgraded, or replaced independently of the others. Layering also provides isolation, in that different mechanisms at the same layer can be used by different organizations without adversely impacting other layers.


There are three layers in this architecture (Figure 1). Note that these layer numbers are different from the layer numbers in the TCP/IP stack, which describe the path of data packets.


   +--------------------------+         +------------------------+
   |                          |         |                        |
   |       to other peers     |         |   to other peers       |
   |          ||   //         |         |      ||  //   ||       |
   |          Prefix          |         |    Prefix     Prefix   |
   |       Coordinator        |         |Coordinator  Coordinator|
   +------------||------------+         +-------||----//---------+
                ||Layer 3                       ||   //
   |          Prefix                          Prefix             |
   |       Coordinator=======================Coordinator         |
   |             ^                              ^                |
   |             +----------------+-------------+                |
   |             |       Layer 2  |             |                |
   |     MAAS<---/                |             +---> MAAS       |
   |     ^   ^                    v                    ^         |
   |     .    .                 MAAS                   .         |
   |     .     .Layer 1           ^                    .Layer 1  |
   |     v      v                 .Layer 1             v         |
   | Client   Client              v                 Client       |
   |                           Client                            |
   +--------------------------+         +------------------------+
   |                          |         |                        |
   |       to other peers     |         |   to other peers       |
   |          ||   //         |         |      ||  //   ||       |
   |          Prefix          |         |    Prefix     Prefix   |
   |       Coordinator        |         |Coordinator  Coordinator|
   +------------||------------+         +-------||----//---------+
                ||Layer 3                       ||   //
   |          Prefix                          Prefix             |
   |       Coordinator=======================Coordinator         |
   |             ^                              ^                |
   |             +----------------+-------------+                |
   |             |       Layer 2  |             |                |
   |     MAAS<---/                |             +---> MAAS       |
   |     ^   ^                    v                    ^         |
   |     .    .                 MAAS                   .         |
   |     .     .Layer 1           ^                    .Layer 1  |
   |     v      v                 .Layer 1             v         |
   | Client   Client              v                 Client       |
   |                           Client                            |

Figure 1: An Overview of the Multicast Address Allocation Architecture


Layer 1 A protocol or mechanism that a multicast client uses to request a multicast address from a multicast address allocation server (MAAS). When the server grants an address, it becomes the server's responsibility to ensure that this address is not then reused elsewhere within the address's scope during the lifetime granted.


Examples of possible protocols or mechanisms at this layer include MADCAP [4], HTTP to access a web page for allocation, and IANA static address assignments.


An abstract API for applications to use for dynamic allocation, independent of the Layer 1 protocol/mechanism in use, is given in [11].


Layer 2 An intra-domain protocol or mechanism that MAAS's use to coordinate allocations to ensure they do not allocate duplicate addresses. A MAAS must have stable storage, or some equivalent robustness mechanism, to ensure that uniqueness is preserved across MAAS failures and reboots.


MAASs also use the Layer 2 protocol/mechanism to acquire (from "Prefix Coordinators") the ranges of multicast addresses out of which they may allocate addresses.


In this document we use the term "allocation domain" to mean an administratively scoped multicast-capable region of the network, within which addresses in a specific range may be allocated by a Layer 2 protocol/mechanism.


Examples of protocols or mechanisms at this layer include AAP [5], and manual configuration of MAAS's.


Layer 3 An inter-domain protocol or mechanism that allocates multicast address ranges (with lifetimes) to Prefix Coordinators. Individual addresses may then be allocated out of these ranges by MAAS's inside allocation domains as described above.


Examples of protocols or mechanisms at this layer include MASC [6] (in which Prefix Coordinators are typically routers without any stable storage requirement), and static allocations by AS number as described in [10] (in which Prefix Coordinators are typically human administrators).


Each of the three layers serves slightly different purposes and as such, protocols or mechanisms at each layer may require different design tradeoffs.


4. Scoping
4. 范围界定

To allocate dynamic addresses within administrative scopes, a MAAS must be able to learn which scopes are in effect, what their address ranges and names are, and which addresses or subranges within each scope are valid for dynamic allocation by the MAAS.


The first two tasks, learning the scopes in effect and the address range and name(s) of each scope, may be provided by static configuration or dynamically learned. For example, a MAAS may simply passively listen to MZAP [9] messages to acquire this information.


To determine the subrange for dynamic allocation, there are two cases for each scope, corresponding to small "indivisible" scopes, and big "divisible" scopes. Note that MZAP identifies which scopes are divisible and which are not.


(1) For small scopes, the allocation domain corresponds to the entire topology within the administrative scope. Hence, all MAASs inside the scope may use the entire address range (minus the last

(1) 对于小范围,分配域对应于管理范围内的整个拓扑。因此,作用域内的所有MAAs都可以使用整个地址范围(减去最后一个地址范围)

256 addresses reserved as scope-relative addresses), and use the Layer 2 mechanism/protocol to coordinate allocations. For small scopes, Prefix Coordinators are not involved.


Hence, for small scopes, the effective "allocation domain" area may be different for different scopes. Note that a small, indivisible scope could be larger or smaller than the Allocation Scope used for big scopes (see below).


(2) For big scopes (including the global scope), the area inside the scope may be large enough that simply using a Layer 2 mechanism/protocol may be inefficient or otherwise undesirable. In this case, the scope must span multiple allocation domains, and the Layer 3 mechanism/protocol must be used to divvy up the scoped address space among the allocation domains. Hence, a MAAS may learn of the scope via MZAP, but must acquire a subrange from which to allocate from a Prefix Coordinator.

(2) 对于大范围(包括全局范围),范围内的区域可能足够大,因此仅使用第2层机制/协议可能效率低下或不受欢迎。在这种情况下,作用域必须跨越多个分配域,并且必须使用第3层机制/协议在分配域之间划分作用域地址空间。因此,MAA可以通过MZAP了解范围,但必须从前缀协调器获取要分配的子范围。

For simplicity, the effective "allocation domain" area will be the same for all big scopes, being the granularity at which all big scopes are divided up. We define the administrative scope at this granularity to be the "Allocation Scope".


4.1. Allocation Scope
4.1. 分配范围

The Allocation Scope is a new administrative scope, defined in this document and to be reserved by IANA with values as noted below. This is the scope that is used by a Layer 2 protocol/mechanism to coordinate address allocation for addresses in larger, divisible scopes.


We expect that the Allocation Scope will often coincide with a unicast Autonomous System (AS) boundary.


If an AS is too large, or the network administrator wishes to run different intra-domain multicast routing in different parts of an AS, that AS can be split by manual setup of an allocation scope boundary that is not an AS boundary. This is done by setting up a multicast boundary dividing the unicast AS into two or more multicast allocation domains.


If an AS is too small, and address space is scarce, address space fragmentation may occur if the AS is its own allocation domain. Here, the AS can instead be treated as part of its provider's allocation domain, and use a Layer 2 protocol/mechanism to coordinate allocation between its MAAS's (if any) and those of its provider. An AS should probably take this course of action if:


o it is connected to a single provider,

o 它连接到单个提供商,

o it does not provide transit for another AS, and

o 它不为另一个AS提供运输,以及

o it needs fewer than (say) 256 multicast addresses of larger than AS scope allocated on average.

o 它需要少于(比如)256个大于平均分配范围的多播地址。

4.1.1. The IPv4 Allocation Scope --
4.1.1. IPv4分配范围--

The address space is to be reserved for the Allocation Scope. The ranges, and are to be left unassigned and available for expansion of this space. These ranges should be left unassigned until the space is no longer sufficient.


4.1.2. The IPv6 Allocation Scope -- SCOP 6
4.1.2. IPv6分配作用域--SCOP 6

The IPv6 "scop" value 6 is to be used for the Allocation Scope.


5. Overview of the Allocation Process
5. 分配程序概览

Once Layer 3 allocation has been performed for large, divisible scopes, and each Prefix Coordinator has acquired one or more ranges, then those ranges are passed to all MAAS's within the Prefix Coordinator's domain via a Layer 2 mechanism/protocol.


MAAS's within the domain receive these ranges and store them as the currently allowable addresses for that domain. Each range is valid for a given lifetime (also acquired via the Layer 3 mechanism/protocol) and is not revoked before the lifetime has expired. MAAS's also learn of small scopes (e.g., via MZAP) and store the ranges associated with them.


Using the Layer 2 mechanism/protocol, each MAAS ensures that it will exclude any addresses which have been or will be allocated by other MAAS's within its domain.


When a client needs a multicast address, it first needs to decide what the scope of the intended session should be, and locate a MAAS capable of allocating addresses within that scope.


To pick a scope, the client will either simply choose a well-known scope, such as the global scope, or it will enumerate the available scopes (e.g., by sending a MADCAP query, or by listening to MZAP messages over time) and allow a user to select one.


Locating a MAAS can be done via a variety of methods, including manual configuration, using a service location protocol such as SLP [12], or via a mechanism provided by a Layer 1 protocol itself. MADCAP, for instance, includes such a facility.


Once the client has chosen a scope and located a MAAS, it then requests an address in that scope from the MAAS located. Along with the request it also passes the acceptable range for the lifetimes of the allocation it desires. For example, if the Layer 1 protocol in use is MADCAP, the client sends a MADCAP REQUEST message to the MAAS, and waits for a NAK message or an ACK message containing the allocated information.


Upon receiving a request from a client, the MAAS then chooses an unused address in a range for the specified scope, with a lifetime which both satisfies the acceptable range specified by the client, and is within the lifetime of the actual range.


The MAAS uses the Layer 2 mechanism/protocol to ensure that such an address does not clash with any addresses allocated by other MAASs. For example, if Layer 2 uses manual configuration of non-overlapping ranges, then this simply consists of adhering to the range configured in the local MAAS. If, on the other hand, AAP is used at Layer 2 to provide less address space fragmentation, the MAAS advertises the proposed allocation domain-wide using AAP. If no clashing AAP claim is received within a short time interval, then the address is returned to the client via the Layer 1 protocol/mechanism. If a clashing claim is received by the MAAS, then it chooses a different address and tries again. AAP also allows each MAAS to pre-reserve a small "pool" of addresses for which it need not wait to detect clashes.


If a domain ever begins to run out of available multicast addresses, a Prefix Coordinator in that domain uses the Layer 3 protocol/mechanism to acquire more space.


6. Security Considerations
6. 安全考虑

The architecture described herein does not prevent an application from just sending to or joining a multicast address without allocating it (just as the same is true for unicast addresses today). However, there is no guarantee that data for unallocated addresses will be delivered by the network. That is, routers may drop data for unallocated addresses if they have some way of checking whether a destination address has been allocated. For example, if the border routers of a domain participate in the Layer 2 protocol/mechanism and cache the set of allocated addresses, then data for unallocated


addresses in a range allocated by that domain can be dropped by creating multicast forwarding state with an empty outgoing interface list and/or pruning back the tree branches for those groups.


A malicious application may attempt a denial-of-service attack by attempting to allocate a large number of addresses, thus attempting to exhaust the supply of available addresses. Other attacks include releasing or modifying the allocation of another party. These attacks can be combatted through the use of authentication with policy restrictions (such as a maximum number of addresses that can be allocated by a single party).


Hence, protocols/mechanisms that implement layers of this architecture should be deployable in a secure fashion. For example, one should support authentication with policy restrictions, and should not allow someone unauthorized to release or modify the allocation of another party.


7. Acknowledgments
7. 致谢

Steve Hanna provided valuable feedback on this document. The members of the MALLOC WG and the MBone community provided the motivation for this work.

Steve Hanna对此文件提供了宝贵的反馈。MALLOC工作组和MBone社区的成员为这项工作提供了动力。

8. References
8. 工具书类

[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.

[1] Meyer,D.,“管理范围的IP多播”,BCP 23,RFC 2365,1998年7月。

[2] Mark Handley, "Multicast Session Directories and Address Allocation", Chapter 6 of PhD Thesis entitled "On Scalable Multimedia Conferencing Systems", University of London, 1997.

[2] Mark Handley,“多播会话目录和地址分配”,第6章题为“可扩展多媒体会议系统”的博士论文,伦敦大学,1997。

[3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4 of PhD Thesis entitled "On Scalable Multimedia Conferencing Systems", University of London, 1997.

[3] Mark Handley,《MBOSE性能分析》,第4章题为“可扩展多媒体会议系统”的博士论文,伦敦大学,1997。

[4] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

[4] Hanna,S.,Patel,B.和M.Shah,“多播地址动态客户端分配协议(MADCAP)”,RFC2730,1999年12月。

[5] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in Progress.

[5] Handley,M.和S.Hanna,“多播地址分配协议(AAP)”,正在进行中。

[6] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov, P. and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000.

[6] Estrin,D.,Govindan,R.,Handley,M.,Kumar,S.,Radoslavov,P.和D.Thaler,“多播地址集声明(MASC)协议”,RFC 2909,2000年9月。

[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.

[7] Deering,S.,“IP多播的主机扩展”,STD 5,RFC 1112,1989年8月。

[8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.

[8] Rekhter,Y.和T.Li,“边境网关协议4(BGP-4)”,RFC 17711995年3月。

[9] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.

[9] Handley,M.,Thaler,D.和R.Kermode,“多播作用域公告协议(MZAP)”,RFC 27762000年2月。

[10] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000.

[10] Meyer,D.和P.Lothberg,“233/8中的GLOP寻址”,RFC 27702000年2月。

[11] Finlayson, R., "Abstract API for Multicast Address Allocation", RFC 2771, February 2000.

[11] Finlayson,R.,“多播地址分配的抽象API”,RFC 27712000年2月。

[12] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.

[12] Guttman,E.,Perkins,C.,Veizades,J.和M.Day,“服务位置协议,版本2”,RFC 26081999年6月。

[13] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.

[13] Mills,D.,“网络时间协议(第3版)规范、实施和分析”,RFC13051992年3月。

9. Authors' Addresses
9. 作者地址

Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399

Dave Thaler微软公司华盛顿州雷德蒙微软大道一号98052-6399


Mark Handley AT&T Center for Internet Research at ICSI 1947 Center St, Suite 600 Berkeley, CA 94704

马克·汉德利美国电话电报公司互联网研究中心,位于加利福尼亚州伯克利市ICSI 1947中心街600室,邮编94704


Deborah Estrin Computer Science Dept/ISI University of Southern California Los Angeles, CA 90089

底波拉埃斯特林计算机科学系/洛杉矶南加州大学,CA 90089

10. Full Copyright Statement
10. 完整版权声明

Copyright (C) The Internet Society (2000). All Rights Reserved.


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.






Funding for the RFC Editor function is currently provided by the Internet Society.