Network Working Group C. Olvera
Request for Comments: 3791 Consulintel
Category: Informational P. Nesser, II
Nesser & Nesser Consulting
June 2004
Network Working Group C. Olvera
Request for Comments: 3791 Consulintel
Category: Informational P. Nesser, II
Nesser & Nesser Consulting
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents
当前部署的IETF路由区域标准跟踪和实验文档中IPv4地址的调查
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
本调查工作旨在记录当前部署的IETF路由区域文件化标准中IPv4地址的所有使用情况。为了成功地从全IPv4 Internet过渡到全IPv6 Internet，将采取许多临时步骤。其中一个步骤是发展具有IPv4依赖关系的当前协议。人们希望这些协议（及其实现）将被重新设计为与网络地址无关，但如果不能做到这一点，则至少会同时支持IPv4和IPv6。为此，将调查所有标准（完整、草案和提议）以及实验性RFC，并记录任何相关性。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards. . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards . . . . . . . . . . . . . . . . . . . . . . . 3
5. Proposed Standards. . . . . . . . . . . . . . . . . . . . . . 3
6. Experimental RFCs . . . . . . . . . . . . . . . . . . . . . . 7
7. Summary of Results. . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards. . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards . . . . . . . . . . . . . . . . . . . . . . . 3
5. Proposed Standards. . . . . . . . . . . . . . . . . . . . . . 3
6. Experimental RFCs . . . . . . . . . . . . . . . . . . . . . . 7
7. Summary of Results. . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
This work aims to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. Also, throughout this document there are discussions on how routing protocols might be updated to support IPv6 addresses.
这项工作的目的是记录当前部署的IETF路由区域文件化标准中IPv4地址的所有使用情况。此外，在本文档中还讨论了如何更新路由协议以支持IPv6地址。
This material was originally presented within a single document, but in an effort to have the information in a manageable form, it has subsequently been split into 7 documents conforming to the current IETF main areas (Application [2], Internet [3], Operations & Management [4], Routing [this document], Security [5], Sub-IP [6] and Transport [7]).
本材料最初在一份文件中呈现，但为了使信息具有可管理的形式，随后将其分为符合当前IETF主要领域的7份文件（应用[2]、互联网[3]、运营与管理[4]、路由[本文件]、安全[5]、子IP[6]和传输[7]）。
The general overview, methodology used during documentation and scope of the investigation for the whole 7 documents can be found in the introduction of this set of documents [1].
总体概述、文件编制过程中使用的方法以及整个7份文件的调查范围见本套文件的介绍[1]。
It is important to mention that to perform this study the following classes of IETF standards are investigated: Full, Draft, and Proposed, as well as Experimental. Informational, BCP and Historic RFCs are not addressed. RFCs that have been obsoleted by either newer versions or as they have transitioned through the standards process are also not covered.
值得一提的是，为了进行这项研究，对IETF标准的以下类别进行了调查：完整、草案、建议以及实验。未说明信息性、业务连续性和历史性RFC。更新版本淘汰或通过标准流程转换的RFC也不包括在内。
The main Sections of this document are described below.
本文件的主要章节如下所述。
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, Proposed Standards and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending (around) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if the problems have already been fixed.
第3节、第4节、第5节和第6节分别描述了完整、草案、拟议标准和实验RFC的原始分析。每个RFC依次讨论，从RFC 1开始，到RFC 3100结束。每个RFC的注释本质上是“原始”的。也就是说，每个RFC都是在真空中讨论的，所讨论的问题不会“向前看”，看问题是否已经解决。
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated.
第7节是对第3、4、5和6节中提供的数据的分析。正是在这里，所有的结果都被视为一个整体，并且在以后的RFC中解决的问题被关联起来。
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完整的互联网标准（通常简称为“标准”）是在整个互联网上广泛实施和使用的完全成熟的协议规范。
RIPv2 is only intended for IPv4 networks.
RIPv2仅适用于IPv4网络。
This RFC defines a protocol for IPv4 routing. It is highly assumptive about address formats being IPv4 in nature.
此RFC定义了IPv4路由的协议。地址格式本质上是IPv4，这是高度假设性的。
RIPv2 is only intended for IPv4 networks.
RIPv2仅适用于IPv4网络。
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
标准草案代表IETF中倒数第二个标准级别。只有当存在多个独立的、可互操作的实现时，协议才能实现标准草案。标准草案通常是相当成熟和广泛使用的。
This RFC defines a protocol used for exchange of IPv4 routing information and does not support IPv6 as is defined.
此RFC定义了用于交换IPv4路由信息的协议，不支持定义的IPv6。
4.2. RFC 1772 Application of the Border Gateway Protocol in the Internet
4.2. RFC1772边界网关协议在Internet中的应用
This RFC is a discussion of the use of BGP-4 on the Internet.
本RFC讨论了BGP-4在互联网上的使用。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only.
尽管协议增强没有IPv4依赖项，但基本协议BGP-4仅为IPv4。
Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases Proposed are never implemented or advanced in the IETF standards process. They therefore are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or
拟议标准是介绍性文件。即使是单个实现也没有要求。在许多情况下，在IETF标准过程中从未实施或推进提议。因此，它们通常只是向互联网社区提出的想法。有时缺陷会暴露或消失
they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion.
它们是许多相互竞争的问题解决方案之一。在后一种情况下，不进行讨论，因为这不符合本次讨论的目的。
5.1. RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments
5.1. RFC 1195在TCP/IP和双环境中使用OSI IS-IS进行路由
This document specifies a protocol for the exchange of IPv4 routing information.
本文档指定了用于交换IPv4路由信息的协议。
This document discusses a version of OSPF that is limited to IPv4.
本文档讨论一个仅限于IPv4的OSPF版本。
5.3. RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol
5.3. 边界网关协议的BGP2和BGP3版本中的RFC 1397默认路由播发
BGP2 and BGP3 are both deprecated and therefore are not discussed in this document.
BGP2和BGP3均已弃用，因此本文档不讨论。
The architecture described in this document has no IPv4 dependencies.
本文档中描述的体系结构没有IPv4依赖项。
5.5. RFC 1479 Inter-Domain Policy Routing Protocol Specification: Version 1 (IDPR)
5.5. RFC 1479域间策略路由协议规范：版本1（IDPR）
There are no IPv4 dependencies in this protocol.
此协议中没有IPv4依赖项。
5.6. RFC 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)
5.6. RFC 1517实现无类域间路由（CIDR）的适用性声明
This document deals exclusively with IPv4 addressing issue.
本文档专门讨论IPv4寻址问题。
This document deals exclusively with IPv4 addressing issue.
本文档专门讨论IPv4寻址问题。
5.8. RFC 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
5.8. RFC1519无类域间路由（CIDR）：一种地址分配和聚合策略
This document deals exclusively with IPv4 addressing issue.
本文档专门讨论IPv4寻址问题。
This protocol is an extension to a protocol for exchanging IPv4 routing information.
此协议是用于交换IPv4路由信息的协议的扩展。
This document defines the use of IPv4 multicast to an IPv4 only routing protocol.
本文档定义了IPv4多播对仅IPv4路由协议的使用。
There are no IPv4 dependencies in this protocol other than the fact that it is a new functionality for a routing protocol that only supports IPv4 networks.
此协议中没有IPv4依赖项，只是它是仅支持IPv4网络的路由协议的一项新功能。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only.
尽管协议增强没有IPv4依赖项，但基本协议BGP-4仅为IPv4。
This RFC documents a protocol for exchanging IPv6 routing information and is not discussed in this document.
本RFC记录了一个用于交换IPv6路由信息的协议，本文档中未讨论该协议。
This RFC defines an enhancement for an IPv4 routing protocol and while it has no IPv4 dependencies it is inherently limited to IPv4.
此RFC定义了IPv4路由协议的增强功能，虽然它没有IPv4依赖项，但本质上仅限于IPv4。
This protocol is IPv4 specific, there are numerous references to 32- bit IP addresses.
这个协议是IPv4特定的，有许多32位IP地址的引用。
There are no IPv4 dependencies in this protocol other than the fact that it is a new functionality for a routing protocol that only supports IPv4 networks.
此协议中没有IPv4依赖项，只是它是仅支持IPv4网络的路由协议的一项新功能。
The protocol enhancements have no IPv4 dependencies, even though the base protocol, BGP-4, is IPv4 only routing protocol.
协议增强没有IPv4依赖关系，即使基本协议BGP-4是仅IPv4的路由协议。
5.18. RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
5.18. RFC 2545将BGP-4多协议扩展用于IPv6域间路由
This RFC documents IPv6 routing methods and is not discussed in this document.
本RFC记录了IPv6路由方法，本文档中未讨论。
This document defines an IPv6 specific protocol and is not discussed in this document.
本文档定义了特定于IPv6的协议，在本文档中不作讨论。
This protocol is only defined for IPv4. The document states in the Appendix:
此协议仅为IPv4定义。该文件在附录中说明：
o IPv6 as Delivery and/or Payload Protocol
o IPv6作为交付和/或有效负载协议
This specification describes the intersection of GRE currently deployed by multiple vendors. IPv6 as delivery and/or payload protocol is not included.
本规范描述了当前由多个供应商部署的GRE的交叉点。不包括IPv6作为交付和/或有效负载协议。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol. This specification updates but does not obsolete RFC 1966.
虽然协议增强没有IPv4依赖关系，但基本协议BGP-4是仅IPv4的路由协议。本规范更新了RFC 1966，但并未过时。
In the Abstract:
摘要：
Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
目前，BGP-4只能承载IPv4的路由信息。本文档定义了BGP-4的扩展，使其能够承载多个网络层协议（如IPv6、IPX等）的路由信息。扩展是向后兼容的-支持扩展的路由器可以与不支持扩展的路由器进行互操作。
The document is therefore not examined further in this document.
因此，本文件不作进一步审查。
There are no IPv4 dependencies in this protocol.
此协议中没有IPv4依赖项。
The RFC defines an IPv6 only document and is not concerned in this survey.
RFC定义了一个仅限IPv6的文档，与本次调查无关。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol.
虽然协议增强没有IPv4依赖关系，但基本协议BGP-4是仅IPv4的路由协议。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol.
虽然协议增强没有IPv4依赖关系，但基本协议BGP-4是仅IPv4的路由协议。
This document defines an extension to an IPv4 routing protocol.
本文档定义了IPv4路由协议的扩展。
There are no IPv4 dependencies in this protocol.
此协议中没有IPv4依赖项。
5.29. RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
5.29. RFC 3122对IPv6邻居发现的扩展，用于反向发现规范
This is an IPv6 related document and is not discussed in this document.
这是一份与IPv6相关的文档，本文档中没有讨论。
Experimental RFCs typically define protocols that do not have wide scale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases they are presented as alternatives to the mainstream solution to an acknowledged problem.
实验性RFC通常定义在Internet上没有广泛实施或使用的协议。它们通常在性质上是恰当的，或者在有限的领域中使用。为了允许潜在的互操作性或其他一些潜在的有用场景，它们被记录到互联网社区中。在少数情况下，它们被作为主流解决方案的替代方案来解决一个公认的问题。
This document defines a protocol for IPv4 multicast routing.
本文档定义了IPv4多播路由的协议。
This proposal is IPv4 limited:
本提案仅限于：
This record is designed for easy general purpose extensions in the DNS, and its content is a text string. The RX record will contain three fields: A record identifier, A cost indicator, and An IP address.
此记录是为DNS中的简单通用扩展而设计的，其内容是文本字符串。RX记录将包含三个字段：记录标识符、成本指示器和IP地址。
The three strings will be separated by a single comma. An example of record would thus be:
这三个字符串将由一个逗号分隔。因此，记录的一个例子是：
___________________________________________________________________
| domain | type | record | value |
| - | | | |
|*.27.32.192.in-addr.arpa | IP | TXT | RX, 10, 10.0.0.7|
|_________________________|________|__________|___________________|
___________________________________________________________________
| domain | type | record | value |
| - | | | |
|*.27.32.192.in-addr.arpa | IP | TXT | RX, 10, 10.0.0.7|
|_________________________|________|__________|___________________|
which means that for all hosts whose IP address starts by the three octets "192.32.27" the IP host "10.0.0.7" can be used as a gateway, and that the preference value is 10.
这意味着，对于IP地址以三个八位字节“192.32.27”开头的所有主机，IP主机“10.0.0.7”可以用作网关，首选值为10。
This document defines an IPv7 routing protocol and has been abandoned by the IETF as a feasible design. It is not considered in this document.
本文件定义了IPv7路由协议，IETF已将其作为可行设计放弃。本文件不考虑这一点。
There are no IPv4 dependencies in this protocol other than the fact that it is a new functionality for a routing protocol that only supports IPv4 networks.
此协议中没有IPv4依赖项，只是它是仅支持IPv4网络的路由协议的一项新功能。
6.5. RFC 1863 A BGP/IDRP Route Server alternative to a full mesh routing
6.5. RFC 1863全网状路由的BGP/IDRP路由服务器替代方案
This protocol is both IPv4 and IPv6 aware and needs no changes.
此协议支持IPv4和IPv6，无需更改。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol. This specification has been updated by RFC 2796.
虽然协议增强没有IPv4依赖关系，但基本协议BGP-4是仅IPv4的路由协议。本规范已由RFC 2796更新。
The document specifies a protocol that depends on IPv4 multicast. There are many packet formats defined that show IPv4 usage.
该文档指定了一个依赖于IPv4多播的协议。定义了许多显示IPv4使用情况的数据包格式。
See previous Section for the IPv4 limitation in this protocol.
有关此协议中的IPv4限制，请参见上一节。
6.9. RFC 2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM
6.9. 使用稀疏模式PIM的RFC 2337 ATM路由器间的LIS内IP组播
This protocol is designed for IPv4 multicast.
此协议是为IPv4多播而设计的。
6.10. RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
6.10. RFC 2362协议独立多播稀疏模式（PIM-SM）：协议规范
This protocol is both IPv4 and IPv6 aware and needs no changes.
此协议支持IPv4和IPv6，无需更改。
There are IPv4 dependencies in this protocol. It requires the use of the IPv4 TOS header field.
此协议中存在IPv4依赖项。它需要使用IPv4 TOS标头字段。
In the initial survey of RFCs, 23 positives were identified out of a total of 46, broken down as follows:
在对RFC的初步调查中，在总共46个样本中，确定了23个阳性样本，细分如下：
Standards: 3 out of 3 or 100.00% Draft Standards: 1 out of 3 or 33.33% Proposed Standards: 13 out of 29 or 44.83% Experimental RFCs: 6 out of 11 or 54.54%
标准：三分之三或100.00%标准草案：三分之一或33.33%拟定标准：29分之十三或44.83%实验性RFC：11分之六或54.54%
Of those identified many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that should be updated but do not cause any operational impact if they are not updated. The remaining instances are documented below. The authors have attempted to organize the results in a format that allows easy reference to other protocol designers. The assignment of statements has been based entirely on the authors perceived needs for updates and should not be taken as an official statement.
在已确定的协议中，许多协议不需要采取行动，因为它们记录了过时和未使用的协议，而其他协议则记录了相关工作组正在积极更新的协议。此外，还有许多应更新的标准实例，但如果不更新，则不会造成任何运营影响。其余实例记录如下。作者试图以一种便于其他协议设计者参考的格式组织结果。声明的分配完全基于作者认为的更新需求，不应被视为官方声明。
This problem has been fixed by RFC 2081, RIPng Protocol Applicability Statement.
RFC 2081《RIPng协议适用性声明》已修复了该问题。
This problem has been fixed by RFC 2740, OSPF for IPv6.
此问题已由RFC 2740，用于IPv6的OSPF修复。
This problem has been fixed by RFC 2080, RIPng for IPv6.
此问题已由RFC 2080（IPv6的RIPng）修复。
This problem has been fixed in RFC 2858 Multiprotocol Extensions for BGP-4, RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, and in [8].
此问题已在用于BGP-4的RFC 2858多协议扩展、用于IPv6域间路由的RFC 2545使用BGP-4多协议扩展以及[8]中修复。
RFC 2858 extends BGP to support multi-protocol extensions that allows routing information for other address families to be exchanged. RFC 2545 further extends RFC 2858 for full support of exchanging IPv6 routing information and additionally clarifies support of the extended BGP-4 protocol using TCP+IPv6 as a transport mechanism. RFC 1771, 2858 & 2545 must be supported in order to provide full IPv6 support.
RFC 2858扩展了BGP以支持多协议扩展，允许交换其他地址族的路由信息。RFC 2545进一步扩展了RFC 2858，以完全支持交换IPv6路由信息，并进一步阐明了对使用TCP+IPv6作为传输机制的扩展BGP-4协议的支持。为了提供完整的IPv6支持，必须支持RFC 1771、2858和2545。
Note also that all the BGP extensions analyzed previously in this memo function without changes with the updated version of BGP-4.
还要注意的是，本备忘录中之前分析的所有BGP扩展功能与更新版本的BGP-4没有任何变化。
7.3.1. Use of OSI IS-IS for routing in TCP/IP and dual environments (RFC 1195)
7.3.1. OSI IS-IS用于TCP/IP和双环境中的路由（RFC 1195）
This problem is being addressed by the IS-IS WG [9].
is-is工作组正在解决这个问题[9]。
This problem has been resolved in RFC 2740, OSPF for IPv6.
此问题已在RFC 2740、用于IPv6的OSPF中得到解决。
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
本规范的内容已在各种IPv6寻址体系结构RFC中处理，请参阅RFC 3513和3587。
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
本规范的内容已在各种IPv6寻址体系结构RFC中处理，请参阅RFC 3513和3587。
7.3.5. Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (RFC 1519)
7.3.5. 无类域间路由（CIDR）：一种地址分配和聚合策略（RFC1519）
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
本规范的内容已在各种IPv6寻址体系结构RFC中处理，请参阅RFC 3513和3587。
This problem has been addressed in RFC 2080, RIPng for IPv6.
此问题已在RFC 2080、IPv6的RIPng中解决。
This functionality has been covered in RFC 2740, OSPF for IPv6.
RFC 2740，用于IPv6的OSPF中介绍了此功能。
This functionality has been covered in RFC 2740, OSPF for IPv6.
RFC 2740，用于IPv6的OSPF中介绍了此功能。
This functionality is provided in RFC 2080, RIPng for IPv6.
此功能在RFC 2080《IPv6的RIPng》中提供。
The problems identified are being addressed by the VRRP WG [10].
VRRP工作组正在解决确定的问题[10]。
This problem has been fixed by RFC 2740, OSPF for IPv6. Opaque options support is an inbuilt functionality in OSPFv3.
此问题已由RFC 2740，用于IPv6的OSPF修复。不透明选项支持是OSPFv3中的内置功能。
Even though GRE tunneling over IPv6 has been implemented and used, its use has not been formally specified. Clarifications are required.
尽管已经实现并使用了IPv6上的GRE隧道，但尚未正式指定其用途。需要澄清。
This functionality has been covered in RFC 2740, OSPF for IPv6.
RFC 2740，用于IPv6的OSPF中介绍了此功能。
This protocol is a routing protocol for IPv4 multicast routing. It is no longer in use and need not be redefined.
此协议是IPv4多播路由的路由协议。它已不再使用，无需重新定义。
This protocol relies on IPv4 DNS RR, but is no longer relevant has never seen much use; no action is necessary.
该协议依赖于IPv4 DNS RR，但不再相关，也没有太多用途；不需要采取任何行动。
This protocol relies on IPv4 IGMP Multicast and a new protocol standard may be produced. However, the multicast routing protocol has never been in much use and is no longer relevant; no action is necessary.
该协议依赖于IPv4 IGMP多播，可能会产生新的协议标准。然而，多播路由协议从未被广泛使用，也不再相关；不需要采取任何行动。
See previous Section for the limitation in this protocol.
有关本协议的限制，请参见上一节。
7.4.5. Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM (RFC 2337)
7.4.5. 使用稀疏模式PIM（RFC 2337）的ATM路由器间的LIS内IP多播
This protocol is designed for IPv4 multicast. However, Intra-LIS IP multicast among routers over ATM is not believed to be relevant anymore. A new mechanism may be defined for IPv6 multicast.
此协议是为IPv4多播而设计的。然而，在ATM上路由器之间的LIS内部IP多播被认为不再相关。可以为IPv6多播定义一种新机制。
QoS extensions for OSPF were never used for OSPFv2, and there seems to be little need for them in OSPFv3.
OSPF的QoS扩展从未用于OSPFv2，在OSPFv3中似乎不需要它们。
However, if necessary, an update to this document could simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field.
但是，如有必要，本文档的更新可以简单地定义IPv6流量类字段的使用，因为它的定义与IPv4 TOS字段完全相同。
This document examines the IPv6-readiness of routing specification; this does not have security considerations in itself.
本文档检查了路由规范的IPv6就绪性；这本身没有安全考虑。
The original author, Philip J. Nesser II, would like to acknowledge the support of the Internet Society in the research and production of this document.
原作者Philip J.Nesser II感谢互联网协会在本文件的研究和制作过程中给予的支持。
He also would like to thanks his partner in all ways, Wendy M. Nesser.
他还想从各个方面感谢他的合作伙伴Wendy M.Nesser。
Cesar Olvera would like to thanks Pekka Savola for an extended guidance and comments for the edition of this document, and Jordi Palet for his support and reviews.
Cesar Olvera感谢Pekka Savola为本文件的编辑提供了广泛的指导和意见，并感谢Jordi Palet的支持和评论。
Additionally, he would further like to thank Andreas Bergstrom, Brian Carpenter, Jeff Haas, Vishwas Manral, Gabriela Medina, Venkata Naidu, Jeff Parker and Curtis Villamizar for valuable feedback.
此外，他还要感谢安德烈亚斯·伯格斯特罗姆、布赖恩·卡彭特、杰夫·哈斯、维斯瓦斯·曼拉尔、加布里拉·梅迪纳、文卡塔·奈杜、杰夫·帕克和柯蒂斯·维拉米扎提供的宝贵反馈。
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards", RFC 3789, June 2004.
[1] Nesser，II，P.和A.Bergstrom，编辑，“当前部署的IETF标准中IPv4地址调查简介”，RFC 3789，2004年6月。
[2] Sofia, R. and P. Nesser, II, "Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards", RFC 3795, June 2004.
[2] Sofia，R.和P.Nesser，II，“当前部署的IETF应用领域标准中IPv4地址的调查”，RFC 3795，2004年6月。
[3] Mickles, C. and P. Nesser, II, "Internet Area: Survey of IPv4 Addresses Currently Deployed IETF Standards", RFC 3790, June 2004.
[3] Mickles，C.和P.Nesser，II，“互联网领域：当前部署IETF标准的IPv4地址调查”，RFC 37902004年6月。
[4] Nesser, II, P. and A. Bergstrom, "Survey of IPv4 addresses in Currently Deployed IETF Operations & Management Area Standards", RFC 3796, June 2004.
[4] Nesser，II，P.和A.Bergstrom，“当前部署的IETF运营和管理领域标准中IPv4地址的调查”，RFC 37962004年6月。
[5] Nesser, II, P. and A. Bergstrom. "Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards", RFC 3792, June 2004.
[5] Nesser，II，P.和A.Bergstrom。“当前部署的IETF安全区域标准中IPv4地址的调查”，RFC 37922004年6月。
[6] Nesser, II, P. and A. Bergstrom. "Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards", RFC 3793, June 2004.
[6] Nesser，II，P.和A.Bergstrom。“当前部署的IETF子IP区域标准中IPv4地址的调查”，RFC 37932004年6月。
[7] Nesser, II, P. and A. Bergstrom "Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards", RFC 3794, June 2004.
[7] Nesser，II，P.和A.Bergstrom，“当前部署的IETF传输区标准中IPv4地址的调查”，RFC 37942004年6月。
[8] Chen, E. and J. Yuan, "AS-wide Unique BGP Identifier for BGP-4", Work in Progress, December 2003.
[8] Chen，E.和J.Yuan，“作为BGP-4的宽唯一BGP标识符”，正在进行的工作，2003年12月。
[9] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, January 2003.
[9] Hopps，C.，“使用IS-IS路由IPv6”，正在进行的工作，2003年1月。
[10] Hinden, R., "Virtual Router Redundancy Protocol for IPv6", Work in Progress, February 2004.
[10] Hinden，R.，“IPv6虚拟路由器冗余协议”，正在进行的工作，2004年2月。
Please contact the authors with any questions, comments or suggestions at:
如有任何问题、意见或建议，请联系作者：
Cesar Olvera Morales Researcher Consulintel San Jose Artesano, 1 28108 - Alcobendas Madrid, Spain
塞萨尔·奥尔维拉·莫拉莱斯研究员，圣何塞·阿尔特萨诺领事，128108-西班牙马德里阿尔科本达斯
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
EMail: cesar.olvera@consulintel.es
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
EMail: cesar.olvera@consulintel.es
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
Philip J.Nesser II首席Nesser&Nesser Consulting 13501东北第100大道，华盛顿州柯克兰市5202号，邮编：98034
Phone: +1 425 481 4303
EMail: phil@nesser.com
Phone: +1 425 481 4303
EMail: phil@nesser.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。