Network Working Group R. Kermode
Request for Comments: 3269 Motorola
Category: Informational L. Vicisano
Cisco
April 2002
Network Working Group R. Kermode
Request for Comments: 3269 Motorola
Category: Informational L. Vicisano
Cisco
April 2002
Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents
编写可靠多播传输（RMT）构建块指南和协议实例化文档
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed.
本文档提供了帮助可靠多播传输（RMT）构建块和协议实例化定义的作者的一般指南。这些指南的目的是确保生成的任何构建块和协议实例化定义包含充分的信息，以充分解释其操作和使用。此外，这些指南提供了指定模块化和明确定义的RMT构建块和协议实例化的方向，这些模块和协议实例化可以被细化和扩充，以安全地创建新协议，用于任何现有协议都未设计的新场景。
Table of Contents
目录
1 Introduction ................................................... 2
1.1 Terminology .................................................. 3
2 The Guidelines ................................................. 3
2.1 Building Block Document Guidelines ........................... 3
2.1.1 Rationale .................................................. 3
2.1.2 Functionality .............................................. 4
2.1.3 Applicability Statement .................................... 4
2.1.4 Packet-Header Fields ....................................... 4
2.1.5 Requirements from other Building Blocks .................... 5
2.1.6 Security Considerations .................................... 5
2.1.7 Codepoint Considerations ................................... 6
2.1.8 Summary Checklist .......................................... 6
2.2 Protocol Instantiation Document Guidelines ................... 7
1 Introduction ................................................... 2
1.1 Terminology .................................................. 3
2 The Guidelines ................................................. 3
2.1 Building Block Document Guidelines ........................... 3
2.1.1 Rationale .................................................. 3
2.1.2 Functionality .............................................. 4
2.1.3 Applicability Statement .................................... 4
2.1.4 Packet-Header Fields ....................................... 4
2.1.5 Requirements from other Building Blocks .................... 5
2.1.6 Security Considerations .................................... 5
2.1.7 Codepoint Considerations ................................... 6
2.1.8 Summary Checklist .......................................... 6
2.2 Protocol Instantiation Document Guidelines ................... 7
2.2.1 Applicability Statement .................................... 7
2.2.2 Architecture Definition .................................... 7
2.2.3 Conformance Statement ...................................... 8
2.2.4 Functionality Definition ................................... 8
2.2.5 Packet Formats ............................................. 9
2.2.6 Summary Checklist .......................................... 9
3 IANA Considerations ............................................ 9
4 Acknowledgements ............................................... 10
5 References ..................................................... 10
6 Authors' Addresses ............................................. 11
7 Full Copyright Statement ....................................... 12
2.2.1 Applicability Statement .................................... 7
2.2.2 Architecture Definition .................................... 7
2.2.3 Conformance Statement ...................................... 8
2.2.4 Functionality Definition ................................... 8
2.2.5 Packet Formats ............................................. 9
2.2.6 Summary Checklist .......................................... 9
3 IANA Considerations ............................................ 9
4 Acknowledgements ............................................... 10
5 References ..................................................... 10
6 Authors' Addresses ............................................. 11
7 Full Copyright Statement ....................................... 12
Reliable Multicast Transport (RMT) protocols can be constructed in a variety of ways, some of which will work better for certain situations than others. It is believed that the requirements space for reliable multicast transport is sufficiently diverse that no one protocol can meet all the requirements [RFC2887]. However, it is also believed that there is sufficient commonality between the various approaches that it should be possible to define a number of building blocks [RFC3048] from which the various RMT protocols can be constructed.
可靠多播传输（RMT）协议可以以多种方式构造，其中一些协议在某些情况下比其他协议工作得更好。人们相信，可靠多播传输的需求空间是充分多样的，没有一个协议能够满足所有需求[RFC2887]。然而，人们还认为，各种方法之间有足够的共性，因此应该可以定义许多构建块[RFC3048]，从这些构建块可以构建各种RMT协议。
One key benefit of this approach is that the same building block can be used multiple times in different protocol instantiations. Another key benefit is that building blocks may be upgraded as experience and understanding is gained. For this operation to be possible the building block needs to be clearly defined in terms of what it does, how it interacts with other building blocks, and how it fits into the overall architecture of a protocol instantiation. This description should also be sufficiently detailed so that those wishing to improve upon a particular building block or protocol instantiation can do so with a full understanding of the design decisions and tradeoffs that were made earlier.
这种方法的一个关键好处是，相同的构建块可以在不同的协议实例化中多次使用。另一个关键好处是，随着经验和理解的积累，构建模块可能会升级。为了使此操作成为可能，需要根据构建块的功能、它与其他构建块的交互方式以及它如何适应协议实例化的总体架构来明确定义构建块。该描述还应足够详细，以便那些希望改进特定构建块或协议实例化的人能够在充分理解之前做出的设计决策和权衡的情况下进行改进。
The building block approach also presents some dangers that must be well understood in order to avoid potential specification flaws.
构建块方法还提出了一些必须充分理解的危险，以避免潜在的规范缺陷。
The most important danger is related to inappropriate usage of building blocks. Although efforts should be made in order to produce a modular and reusable specification of building blocks, for practical reasons this goal is not always fully achievable. This results in the specification of building blocks whose applicability is context dependent, which in turn creates the potential for the risk of co-dependence incompatibilities between building blocks. An example of such an incompatibility would be situation where the
最重要的危险与不恰当地使用积木有关。尽管应该做出努力，以产生模块化和可重用的构建块规范，但出于实际原因，这一目标并不总是完全可以实现的。这就产生了适用性依赖于上下文的构建块规范，这反过来又产生了构建块之间相互依赖不兼容的潜在风险。这种不兼容的一个例子是
combinations of building blocks A and B works, the combination of building blocks B and C works, however the combination of building blocks A, B, and C does not work.
构建块A和B的组合起作用，构建块B和C的组合起作用，但是构建块A、B和C的组合不起作用。
In order to avoid misusage of and incompatibilities between building blocks, any external dependency must be highlighted in the building block specification. Furthermore, the specification must contain a precise applicability statement for the building block. Conversely, any protocol instantiation specification must state how any building block being used in it meets the protocol instantiation's applicability requirements. These guidelines are not intended to replace the common practice of Internet specification writing, but to augment them in a manner that better fits the RMT framework.
为了避免构建块之间的误用和不兼容，必须在构建块规范中突出显示任何外部依赖关系。此外，规范必须包含构建块的精确适用性声明。相反，任何协议实例化规范都必须说明其中使用的任何构建块如何满足协议实例化的适用性要求。这些指南的目的不是要取代互联网规范编写的常规做法，而是以更适合RMT框架的方式对其进行扩充。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document provides guidelines for authors of the two main kinds of RMT documents; building block documents and protocol instantiation documents. The guidelines for each are as follows.
本文件为两种主要RMT文件的作者提供指南；构建块文档和协议实例化文档。每一项的指导方针如下。
All RMT Building block documents MUST contain sections that cover the following.
所有RMT构建块文档必须包含以下章节。
Individual building blocks SHOULD be reusable within multiple protocols and MUST provide functionality not present within other building blocks. If a building block is currently used in a single protocol instantiation, then it MUST specify some functionality that is likely to be reused in another (future) protocol instantiation.
单个构建块应在多个协议中可重用，并且必须提供其他构建块中不存在的功能。如果构建块当前用于单个协议实例化，那么它必须指定一些可能在另一个（未来）协议实例化中重用的功能。
The rationale section of a building block document must clearly define why the particular level of granularity for the functional decomposition resulted in that building block being chosen. If the granularity is too small it is highly likely that the building blocks will be trivial, and therefore require excessive additional effort to realize a working protocol. Conversely, if the level of granularity is too large, building blocks will only be usable within a single protocol instantiation. The rationale section MUST show that the level of granularity is appropriate so that neither problem occurs.
构建块文档的基本原理部分必须明确定义为什么功能分解的特定粒度级别导致选择该构建块。如果粒度太小，则构建块很可能微不足道，因此需要额外的努力来实现工作协议。相反，如果粒度级别太大，则构建块只能在单个协议实例化中使用。基本原理部分必须说明粒度级别是适当的，这样就不会出现任何问题。
The functionality section within a building block document MUST describe all algorithms and functions contained within the building block. In addition, the external interfaces for accessing these algorithms and functions MUST be fully specified so that the building block can be combined with other building blocks and any additional functionality specified within a protocol instantiation document to realize a working protocol.
构建块文档中的功能部分必须描述构建块中包含的所有算法和功能。此外，必须完全指定用于访问这些算法和功能的外部接口，以便构建块可以与协议实例化文档中指定的其他构建块和任何附加功能相结合，以实现工作协议。
One of the most important sections of a building block document will be the Applicability Statement. The purpose of this section is to provide sufficient details about the intended use of the building block so that potential authors of protocol instantiations will be able to use the building block in conformance to its applicability constraints. Also the Applicability Statement section will enable future building block document authors to quickly determine whether or not their particular need can be met with an existing building block. For this to be possible the Applicability Statement MUST describe:
构建块文档最重要的部分之一是适用性声明。本节的目的是提供有关构建块预期用途的足够详细信息，以便协议实例化的潜在作者能够根据其适用性约束使用构建块。此外，适用性声明部分将使未来的构建块文档作者能够快速确定其特定需求是否可以通过现有构建块得到满足。为此，适用性声明必须说明：
o Intended scenarios for the building block's use.
o 构建块使用的预期场景。
o The building block's known failure modes, why they occur, and how they can be detected.
o 构建块的已知故障模式、发生原因以及如何检测。
o A list of environmental considerations that includes but is not limited to whether the building block requires multi-source multicast or can be used in single-source only multicast networks, satellite networks, asymmetric networks, and wireless networks.
o 环境注意事项列表，包括但不限于构建块是否需要多源多播或是否可用于单源多播网络、卫星网络、非对称网络和无线网络。
o A list of potential areas of conflict or incompatibilities with other building blocks.
o 与其他构建块冲突或不兼容的潜在区域列表。
If a building block implements a functionality whose realization requires an exchange of protocol messages between multiple agents, then the building block specification MUST state what kind of information is required and how the exchanged occurs. This includes detailed description of the data format and various communication requirements, such as timing constraints, and network requirements (e.g., multicast vs. unicast delivery).
如果构建块实现的功能需要在多个代理之间交换协议消息，那么构建块规范必须说明需要什么类型的信息以及如何进行交换。这包括对数据格式和各种通信要求的详细描述，例如定时约束和网络要求（例如，多播与单播传送）。
Typically the data format specification is at the level of "generic header fields" without a full bit-level header specification. Generic header fields MAY specify additional requirements, such as representation precision or preferred position within the packet header (this last constraint might be dictated by efficiency concerns).
通常，数据格式规范处于“通用头字段”级别，没有完整的位级别头规范。通用报头字段可以指定其他要求，例如表示精度或数据包报头中的首选位置（最后一个约束可能由效率问题决定）。
A building block specification MAY specify "abstract messages" that carry particular information for exclusive use within the building block, however, more frequently, it will rely on the protocol messages specified in the protocol instantiation to carry the information it needs.
构建块规范可以指定携带特定信息以供构建块内专用的“抽象消息”，然而，更频繁地，它将依赖协议实例化中指定的协议消息来携带它所需的信息。
The building block that provides Generic Router Assist functionality is an exception to the rule stated above. For efficiency reasons, this building block may fully specify header fields and positions of these fields within the packet-header.
提供通用路由器辅助功能的构建块是上述规则的例外。出于效率原因，此构建块可以完全指定报头字段以及这些字段在分组报头中的位置。
Each building block will specify a well defined piece of functionality that is common to multiple protocol instantiations. However, this does not mean that building block definitions will be generated in isolation from other building blocks. For example, a congestion control building block will have specific requirements regarding loss notification from either a NACK or ACK building block. The "Requirements from other Building Blocks" section is included to capture these requirements so that the authors of related building blocks can determine what functionality they need to provide in order to use a particular building block.
每个构建块将指定一个定义良好的功能块，该功能块对于多个协议实例化是通用的。但是，这并不意味着构建块定义将与其他构建块隔离生成。例如，拥塞控制构建块将对来自NACK或ACK构建块的丢失通知具有特定要求。“来自其他构建块的需求”部分用于捕获这些需求，以便相关构建块的作者可以确定他们需要提供什么功能才能使用特定的构建块。
Specifically, the "Requirements from other Building Blocks section" MUST provide a complete and exhaustive enumeration of all the requirements that will be made upon other building blocks in order for the building block being specified to operate in its intended manner. Requirements that SHOULD be enumerated include but are not limited to:
具体而言，“其他构建块的要求”部分必须提供对其他构建块的所有要求的完整且详尽的列举，以便指定的构建块以其预期方式运行。应列举的要求包括但不限于：
o Event generation for and responses to other building blocks.
o 其他构建块的事件生成和响应。
o Message ordering relative to messages from other building blocks.
o 相对于来自其他构建块的消息的消息顺序。
Protocol instantiations have the ultimate responsibility of addressing security requirements, in conformance to RFC 2357. Security considerations may not be applicable to generic building blocks other than a specific "security" building block. Some
协议实例化的最终责任是根据RFC 2357解决安全需求。安全注意事项可能不适用于除特定“安全”构建块之外的通用构建块。一些
building blocks, however, may raise special security issues, either due to the nature of communication required by the building block or due to the intended usage of the building block in a protocol instantiation. When special security issues are present in a building block, its specification MUST address them explicitly.
然而，构建块可能会引起特殊的安全问题，这可能是由于构建块所需的通信的性质，也可能是由于构建块在协议实例化中的预期用途。当构建块中存在特殊的安全问题时，其规范必须明确地解决这些问题。
An example of this might be a building block that involves exchange of data that is particularly sensitive to security attacks.
这方面的一个例子可能是涉及对安全攻击特别敏感的数据交换的构建块。
Certain Building Blocks will specify general frameworks for describing functionality while leaving the detail open for implementation specific algorithms. One example of such a building block is the Forward Error Correction (FEC) building block which describes the framing aspects for FEC message fragments but not the algorithms used to generate the redundant data.
某些构建块将指定用于描述功能的通用框架，同时为特定于实现的算法保留细节。这种构建块的一个示例是前向纠错（FEC）构建块，其描述了FEC消息片段的帧方面，但不描述用于生成冗余数据的算法。
Rationale _ Provide justification for the building block's existence _ Provide rationale for the building block's granularity
理由-为构建块的存在提供理由-为构建块的粒度提供理由
Functionality _ Functionality contained within the building block _ External interfaces
功能性uu构建块内包含的功能性uuu外部接口
Applicability Statement _ Intended usage _ Failure modes (including means of detection if known) _ Environmental considerations _ Incompatibilities / Conflicts with other building blocks
适用性声明uu预期用途uu故障模式（包括已知的检测手段）uu环境因素uu与其他构件不兼容/冲突
Packet Header Fields _ Specification of logical packet-header fields (*) _ Abstract messages specifications (*)
数据包头字段\逻辑数据包头字段的规范（*）\抽象消息规范（*）
Requirements from other building blocks; _ Mandatory needs from other building blocks
来自其他构建块的要求；\u其他构建模块的强制性需求
Security Considerations _ Specify as much as possible (with respect to procedures, algorithms and data encoding), without affecting the general applicability of the building block.
安全注意事项——在不影响构建块的一般适用性的情况下，尽可能详细说明（关于过程、算法和数据编码）。
(*) May not be applicable to some building blocks.
（*）可能不适用于某些构建块。
Protocol Instantiation documents have one purpose: to specify how one can combine multiple building blocks to construct a new fully specified working protocol. To that end RMT Protocol Instantiation documents MUST contain the following four sections.
协议实例化文档有一个目的：指定如何组合多个构建块来构建新的完全指定的工作协议。为此，RMT协议实例化文档必须包含以下四个部分。
The applicability statement's purpose is to frame the design space in which the fully realized protocol will operate and to thereby enable subsequent would-be RMT protocol designers to determine whether or not an existing protocol already meets their needs. For this to be possible the applicability statement MUST adhere to the following guidelines:
适用性声明的目的是确定完全实现的协议将在其中运行的设计空间，从而使后续的潜在RMT协议设计者能够确定现有协议是否已经满足其需求。为此，适用性声明必须遵守以下指南：
1) The target application space for which the protocol is intended MUST be clearly identified. For example; is the protocol to be used for real-time delivery, or non-real time file transfer?
1) 协议所针对的目标应用程序空间必须明确标识。例如协议是用于实时传递还是用于非实时文件传输？
2) The target scale, in terms of maximum number of receivers per session, for which the protocol is intended MUST be clearly specified. If the protocol has an architectural limitation resulting from the optimization of another feature, such as per packet acknowledgment, this SHOULD be included.
2) 必须明确规定协议拟用于的目标规模，即每个会话的最大接收器数量。如果协议因优化另一个特性（如每包确认）而存在架构限制，则应包括该限制。
3) The applicability statement MUST identify the intended environments for the protocol's use AND list any environments in which the protocol should not be used. Example environments that should be considered include asymmetric networks, wireless networks, and satellite networks.
3) 适用性声明必须确定协议使用的预期环境，并列出不应使用协议的任何环境。应考虑的示例环境包括不对称网络、无线网络和卫星网络。
4) Finally, all protocols have inherent weaknesses that stem from the optimization for a specific feature. These weaknesses can manifest in spectacular failure modes when certain conditions occur. When known, these conditions and the nature of how the subsequent failure can be detected MUST be included in the applicability statement.
4) 最后，所有协议都有固有的弱点，这些弱点源于对特定功能的优化。当某些情况发生时，这些弱点可能表现为壮观的故障模式。已知时，这些条件以及如何检测后续故障的性质必须包含在适用性声明中。
Protocol Instantiations define how to combine one or more building blocks to create a working protocol. The Architecture Definition lays out the framework for how this take place. For this framework to be complete, it MUST contain the following information:
协议实例化定义了如何组合一个或多个构建块来创建工作协议。架构（Architecture）定义列出了如何实现这一点的框架。要使此框架完整，它必须包含以下信息：
1) An overview of the major facets of the protocol's operation.
1) 协议运行的主要方面概述。
2) Full enumeration and overview of which Building Blocks are used with explicit references to their documents that define them.
2) 使用哪些构建块的完整枚举和概述，并明确引用定义它们的文档。
3) An overview of how the aforementioned building blocks are to be joined.
3) 概述如何连接上述构建块。
4) A discussion of the design tradeoffs made in the selection of the chosen architecture.
4) 讨论在选择所选架构时所作的设计权衡。
The conformance statement below MUST be included and adhered to:
必须包括并遵守以下合规性声明：
"This Protocol Instantiation document, in conjunction with the following Building Block documents identified in [list of relevant building block references] completely specifies a working reliable multicast transport protocol that conforms to the requirements described in RFC 2357."
“本协议实例化文档与[相关构建块参考列表]中确定的以下构建块文档一起，完全指定了一个工作可靠的多播传输协议，该协议符合RFC 2357中描述的要求。”
Protocol instantiation document authors are specifically reminded that RFC 2357 requires that any RMT protocol put forward for standardization with the IETF is required to protect the network in as much as is possible. This does not mean that RMT protocols will be held to a higher standard than unicast transport protocols, merely that they should be designed to perform at least as well as unicast transport protocols when it comes to the possibility of protocol failure.
特别提醒协议实例化文件的作者，RFC 2357要求为IETF标准化而提出的任何RMT协议都必须尽可能地保护网络。这并不意味着RMT协议将比单播传输协议具有更高的标准，仅仅是当涉及到协议故障的可能性时，RMT协议的性能应至少与单播传输协议一样好。
Building Block documents will be incomplete in that they will specify an abstract framework of a building block's functionality. Complete algorithmic specifications for each building block along with any additional functionality MUST be provided within the Protocol Instantiation document's functionality definition. Furthermore, this description must show that each building block is used in accordance with its respective applicability statement. Finally the functionality description must provide a description of the abstract programming interface for interfacing the protocol instantiation with the applications that will use it.
构建块文档将是不完整的，因为它们将指定构建块功能的抽象框架。必须在协议实例化文档的功能定义中提供每个构建块的完整算法规范以及任何附加功能。此外，该说明必须表明，每个构建块的使用符合其各自的适用性声明。最后，功能描述必须提供抽象编程接口的描述，用于将协议实例化与将使用它的应用程序接口。
Once all the functionality has been fully defined, the Protocol Instantiation document must define the packet formats that will be used by the protocol. Each message part and the rules for their concatenation MUST be specified for both IPv4 [RFC791] and IPv6 [RFC2460]. Support for IPSEC [RFC2401] MUST be explicitly shown.
一旦完全定义了所有功能，协议实例化文档必须定义协议将使用的数据包格式。必须为IPv4[RFC791]和IPv6[RFC2460]指定每个消息部分及其连接规则。必须明确显示对IPSEC[RFC2401]的支持。
In recognition of the fact that protocols will evolve and that IP protocol numbers are a scarce resource, protocol instantiations MUST initially define packet formats for use over UDP [RFC768]. Whether or not a particular Reliable Multicast Transport protocol instantiation becomes sufficiently popular to warrant its own protocol number is an issue which will be deferred until such time that the protocol has been sufficiently widely deployed and understood.
认识到协议将不断发展，IP协议编号是稀缺资源，协议实例化必须首先定义UDP上使用的数据包格式[RFC768]。一个特定的可靠多播传输协议实例化是否变得足够流行以保证其自身的协议编号是一个问题，这个问题将被推迟到该协议已被充分广泛部署和理解为止。
Applicability Statement _ Target application space _ Target scale _ Intended environment _ Weaknesses and known failure modes
适用性声明uu目标应用空间uu目标规模uu预期环境uuu弱点和已知故障模式
Architecture Definition _ Operational overview _ Building blocks used _ Details on how building blocks are joined
架构定义uu操作概述uu使用的构建块uu如何连接构建块的详细信息
Conformance Statement _ Inclusion of mandatory paragraph
合规性声明uu包含强制性段落
Functionality Definition _ Building block algorithmic specification _ Addition functionality specification _ Compliance with building block applicability statements _ Abstract program interface
功能定义uu构建块算法规范uu添加功能规范uu符合构建块适用性声明uu抽象程序接口
Packet Formats _ IPv4 message parts _ IPv6 message parts _ IPSEC support _ Message ordering
数据包格式uIPv4消息部分uIPv6消息部分uIPSec支持uu消息顺序
There are no explicit IANA considerations for this document.
本文件没有明确的IANA注意事项。
This document represents an overview of the mandatory elements required for the specification of building blocks and protocol instantiations within the RMT working group. The requirements presented are a summarization of discussions held between the RMT Working Group chairs and the participants in the IRTF Reliable Multicast Research Group. Although the name of these participants are too numerous to list here, the Working Group chairs would like to thank everyone who has participated in these discussions for their contributions.
本文件概述了RMT工作组内规范构建块和协议实例化所需的强制性要素。提出的要求是RMT工作组主席和IRTF可靠多播研究组参与者之间讨论的总结。虽然这些与会者的名字太多，无法在此列出，但工作组主席要感谢参加这些讨论的每一个人所作的贡献。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC791] Postel, J., "Darpa Internet Protocol Specification", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“Darpa互联网协议规范”，标准5，RFC7911981年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC2460，1998年12月。
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L. and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC2887]Handley，M.，Floyd，S.，Whetten，B.，Kermode，R.，Vicisano，L.和M.Luby，“批量数据传输的可靠多播设计空间”，RFC 2887，2000年8月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048]Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany NSW 1455, Australia.
Roger Kermode摩托罗拉澳大利亚研究中心锁袋5028植物新南威尔士1455，澳大利亚。
EMail: Roger.Kermode@motorola.com
EMail: Roger.Kermode@motorola.com
Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA
Lorenzo Vicisano Cisco Systems，170 West Tasman Dr.San Jose，CA 95134，美国
EMail: lorenzo@cisco.com
EMail: lorenzo@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。