Network Working Group P. Nesser, II
Request for Comments: 3789 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Network Working Group P. Nesser, II
Request for Comments: 3789 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF 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 document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results.
本文档是对v6ops IETF工作组项目的概述和介绍，该项目记录了IETF标准跟踪和实验RFC中IPv4地址的所有使用情况。它被分为七个符合当前IETF领域的文件。它还描述了记录过程中使用的方法，记录了哪些类型的RFC，并提供了结果的串联摘要。
Table of Contents
目录
1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Short Historical Perspective . . . . . . . . . . . . . 2
1.2. An Observation on the Classification of Standards. . . 3
2.0. Methodology. . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . 4
3.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 5
3.1. Application Area Specifications. . . . . . . . . . . . 5
3.2. Internet Area Specifications . . . . . . . . . . . . . 5
3.3. Operations and Management Area Specifications. . . . . 6
3.4. Routing Area Specifications. . . . . . . . . . . . . . 6
3.5. Security Area Specifications . . . . . . . . . . . . . 6
3.6. Sub-IP Area Specifications . . . . . . . . . . . . . . 6
3.7. Transport Area Specifications. . . . . . . . . . . . . 7
4.0. Discussion of "Long Term" Stability of Addresses on
Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.0. Security Considerations. . . . . . . . . . . . . . . . . . . 8
6.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Short Historical Perspective . . . . . . . . . . . . . 2
1.2. An Observation on the Classification of Standards. . . 3
2.0. Methodology. . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . 4
3.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 5
3.1. Application Area Specifications. . . . . . . . . . . . 5
3.2. Internet Area Specifications . . . . . . . . . . . . . 5
3.3. Operations and Management Area Specifications. . . . . 6
3.4. Routing Area Specifications. . . . . . . . . . . . . . 6
3.5. Security Area Specifications . . . . . . . . . . . . . 6
3.6. Sub-IP Area Specifications . . . . . . . . . . . . . . 6
3.7. Transport Area Specifications. . . . . . . . . . . . . 7
4.0. Discussion of "Long Term" Stability of Addresses on
Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.0. Security Considerations. . . . . . . . . . . . . . . . . . . 8
6.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7.0. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . 8
8.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
9.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
7.0. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . 8
8.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
9.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
This document is the introduction to a document set aiming to document all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents, conforming to the current IETF areas (Application [1], Internet [2], Operations and Management [3], Routing [4], Security [5], Sub-IP [6], and Transport [7]). It also describes the methodology used during documentation, which types of RFCs that have been documented, and provides a concatenated summary of results.
本文档介绍了一个文档集，旨在记录IETF标准中IPv4地址的所有使用情况。为了使信息具有可管理的形式，已将其分为7个文档，符合当前IETF领域（应用[1]、互联网[2]、操作和管理[3]、路由[4]、安全[5]、子IP[6]和传输[7]）。它还描述了记录过程中使用的方法，记录了哪些类型的RFC，并提供了结果的串联摘要。
There are many challenges that face the Internet Engineering community. The foremost of these challenges has been the scaling issue: how to grow a network that was envisioned to handle thousands of hosts to one that will handle tens of millions of networks with billions of hosts. Over the years, this scaling problem has been managed, with varying degrees of success, by changes to the network layer and to routing protocols. (Although largely ignored in the changes to network layer and routing protocols, the tremendous advances in computational hardware during the past two decades have been of significant benefit in management of scaling problems encountered thus far.)
互联网工程界面临着许多挑战。这些挑战中最重要的是扩展问题：如何将一个设想中可以处理数千台主机的网络扩展到一个可以处理几千万台网络和数十亿台主机的网络。多年来，通过对网络层和路由协议的更改，这种扩展问题得到了不同程度的成功解决。（尽管在网络层和路由协议的变化中基本上被忽略，但在过去二十年中，计算硬件的巨大进步在管理迄今为止遇到的扩展问题方面具有显著的优势。）
The first "modern" transition to the network layer occurred during the early 1980's, moving from the Network Control Protocol (NCP) to IPv4. This culminated in the famous "flag day" of January 1, 1983. IP Version 4 originally specified an 8 bit network and 24 bit host addresses, as documented in RFC 760. A year later, IPv4 was updated in RFC 791 to include the famous A, B, C, D, and E class system.
第一次向网络层的“现代”过渡发生在20世纪80年代初，从网络控制协议（NCP）过渡到IPv4。这在1983年1月1日著名的“卖旗日”达到了高潮。IP版本4最初指定了8位网络和24位主机地址，如RFC 760中所述。一年后，RFC791对IPv4进行了更新，包括著名的A、B、C、D和E级系统。
Networks were growing in such a way that it was clear that a convention for breaking networks into smaller pieces was needed. In October of 1984 RFC 917 was published formalizing the practice of subnetting.
网络正在以这样一种方式发展，很明显，需要一种将网络分成更小的部分的惯例。1984年10月，RFC 917出版，正式规定了子网的实践。
By the late 1980's, it was clear that the current exterior routing protocol used by the Internet (EGP) was insufficiently robust to scale with the growth of the Internet. The first version of BGP was documented in 1989 in RFC 1105.
到了20世纪80年代末，很明显，互联网（EGP）目前使用的外部路由协议（ExternalRouting protocol）不够健壮，无法随互联网的增长而扩展。BGP的第一个版本于1989年记录在RFC1105中。
Yet another scaling issue, exhaustion of the class B address space became apparent in the early 1990s. The growth and commercialization of the Internet stimulated organisations requesting IP addresses in alarming numbers. By May of 1992, over 45% of the Class B space had been allocated. In early 1993 RFC 1466 was published, directing assignment of blocks of Class C's be given out instead of Class B's. This temporarily circumvented the problem of address space exhaustion, but had a significant impact of the routing infrastructure.
还有一个扩展问题，B类地址空间的耗尽在20世纪90年代初变得明显。互联网的发展和商业化刺激了要求IP地址的组织数量惊人。到1992年5月，已分配了超过45%的B类空间。1993年初，RFC 1466出版，指示分配C类区块，而不是B类区块。这暂时避免了地址空间耗尽的问题，但对路由基础设施产生了重大影响。
The number of entries in the "core" routing tables began to grow exponentially as a result of RFC 1466. This led to the implementation of BGP4 and CIDR prefix addressing. This may have circumvented the problem for the present, but they continue to pose potential scaling issues.
由于RFC 1466，“核心”路由表中的条目数开始呈指数增长。这导致了BGP4和CIDR前缀寻址的实现。目前，这可能已经避免了这个问题，但它们仍然会带来潜在的扩展问题。
Growth in the population of Internet hosts since the mid-1980s would have long overwhelmed the IPv4 address space if industry had not supplied a circumvention in the form of Network Address Translators (NATs). To do this, the Internet has watered down the underlying "End-to-End" principle.
如果业界没有以网络地址转换器（NAT）的形式提供规避措施，自20世纪80年代中期以来，互联网主机数量的增长早就超过了IPv4地址空间。为此，互联网淡化了潜在的“端到端”原则。
In the early 1990's, the IETF was aware of these potential problems and began a long design process to create a successor to IPv4 that would address these issues. The outcome of that process was IPv6.
20世纪90年代初，IETF意识到了这些潜在的问题，并开始了一个漫长的设计过程，以创建IPv4的继任者来解决这些问题。这一进程的结果是IPv6。
The purpose of this document is not to discuss the merits or problems of IPv6. That debate is still ongoing and will eventually be decided on how well the IETF defines transition mechanisms and how industry accepts the solution. The question is not "should," but "when."
本文档的目的不是讨论IPv6的优点或问题。这场辩论仍在进行中，最终将决定IETF如何定义过渡机制以及行业如何接受解决方案。问题不是“应该”，而是“何时”
It has become clear during the course of this investigation that there has been little management of the status of standards over the years. Some attempt has been made by the introduction of the classification of standards into Full, Draft, Proposed, Experimental, and Historic. However, there has not been a concerted effort to actively manage the classification for older standards. Standards are only classified as Historic when either a newer version of the protocol is deployed and it is randomly noticed that an RFC describes a long dead protocol, or a serious flaw is discovered in a protocol. Another issue is the status of Proposed Standards. Since this is the entry level position for protocols entering the standards process, many old protocols or non-implemented protocols linger in this status indefinitely. This problem also exists for Experimental RFCs. Similarly, the problem exists for the Best Current Practices (BCP) and For You Information (FYI) series of documents.
在本次调查过程中，很明显，多年来很少对标准的状态进行管理。通过将标准分类引入完整、草案、提议、试验和历史，已经做出了一些尝试。然而，尚未协调一致地积极管理旧标准的分类。只有当部署了较新版本的协议并且随机发现RFC描述了一个长期失效的协议，或者在协议中发现了严重的缺陷时，标准才会被归类为历史标准。另一个问题是拟议标准的现状。由于这是进入标准过程的协议的入门级位置，许多旧协议或未实现的协议无限期地停留在该状态。这个问题也存在于实验RFC中。同样，当前最佳实践（BCP）和供您参考（FYI）系列文档也存在问题。
To exemplify this point, there are 61 Full Standards, only 4 of which have been reclassified to Historic. There are 65 Draft Standards, 611 Proposed Standards, and 150 Experimental RFCs, of which only 66 have been reclassified as Historic. That is a rate of less than 8%. It should be obvious that in the more that 30 years of protocol development and documentation, there should be at least as many (if not a majority of) protocols that have been retired compared to the ones that are currently active.
为了说明这一点，共有61项完整标准，其中只有4项被重新归类为历史标准。有65项标准草案、611项拟议标准和150项试验性RFC，其中只有66项被重新归类为历史性RFC。这一比率不到8%。显而易见的是，在30多年的协议开发和文档编制过程中，至少有相同数量（如果不是大多数的话）的协议已经失效，与目前正在使用的协议相比。
Please note that there is occasionally some confusion of the meaning of a "Historic" classification. It does NOT necessarily mean that the protocol is not being used. A good example of this concept is the Routing Information Protocol(RIP) version 1. There are many thousands of sites using this protocol even though it has Historic status. There are potentially hundreds of otherwise classified RFC's that should be reclassified.
请注意，“历史”分类的含义偶尔会有一些混淆。这并不一定意味着没有使用该协议。这一概念的一个很好的例子是路由信息协议（RIP）版本1。尽管该协议具有历史地位，但仍有数千个站点使用该协议。可能有数百个其他分类的RFC需要重新分类。
To perform this study, each class of IETF standards are investigated in order of maturity: Full, Draft, and Proposed, as well as Experimental. Informational and BCP RFCs are not addressed. RFCs that have been obsoleted by either newer versions or because they have transitioned through the standards process are not covered. RFCs which have been classified as Historic are also not included.
为了进行这项研究，每一类IETF标准都按照成熟度的顺序进行了调查：完整的、草案的、建议的，以及实验性的。信息性和BCP RFC未得到解决。更新版本或通过标准流程转换而过时的RFC不包括在内。被归类为历史的RFC也不包括在内。
Please note that a side effect of this choice of methodology is that some protocols that are defined by a series of RFC's that are of different levels of standards maturity are covered in different spots in the document. Likewise, other natural groupings (i.e., MIBs, SMTP extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined.
请注意，这种方法选择的一个副作用是，由一系列具有不同标准成熟度级别的RFC定义的一些协议在文档中的不同位置被涵盖。类似地，其他自然分组（即MIB、SMTP扩展、IP over FOO、PPP、DNS等）也很容易想象。
The procedure used in this investigation is an exhaustive reading of the applicable RFC's. This task involves reading approximately 25,000 pages of protocol specifications. To compound this, it was more than a process of simple reading. It was necessary to attempt to understand the purpose and functionality of each protocol in order to make a proper determination of IPv4 reliability. The author has made every effort to produce as complete a document set as possible, but it is likely that some subtle (or perhaps not so subtle) dependence was missed. The author encourages those familiar (designers, implementers or anyone who has an intimate knowledge) with any protocol to review the appropriate sections and make comments.
本调查中使用的程序是对适用RFC的详尽阅读。这项任务涉及阅读约25000页的协议规范。更复杂的是，这不仅仅是一个简单的阅读过程。为了正确确定IPv4的可靠性，有必要尝试了解每个协议的目的和功能。作者已经尽了一切努力来制作尽可能完整的文档集，但是很可能遗漏了一些微妙的（或者可能不是那么微妙的）依赖性。作者鼓励那些熟悉任何协议的人（设计人员、实现人员或任何熟悉协议的人）查看适当的部分并发表评论。
In the initial survey of RFCs, 173 positives were identified out of a total of 877, broken down as follows:
在RFC的初步调查中，在总共877个样本中，确定了173个阳性样本，细分如下：
Standards: 30 out of 68 or 44.12% Draft Standards: 16 out of 68 or 23.53% Proposed Standards: 98 out of 597 or 16.42% Experimental RFCs: 29 out of 144 or 20.14%
标准：68项标准中的30项或44.12%标准草案：68项标准中的16项或23.53%拟定标准：597项标准中的98项或16.42%试验性RFC：144项标准中的29项或20.14%
Of those identified, many require no action because they document outdated and unused protocols, while others are active document protocols being updated by the appropriate working groups (SNMP MIBs for example).
在已确定的协议中，许多协议不需要采取行动，因为它们记录了过时和未使用的协议，而其他协议则是由适当的工作组（例如SNMP MIB）更新的活动文档协议。
Additionally, there are many instances of standards that should be updated but do not cause any operational impact (STD 3/RFCs 1122 and 1123 for example) if they are not updated.
此外，有许多标准应更新，但如果不更新，则不会造成任何运营影响（例如STD 3/RFCs 1122和1123）。
In this statistical survey, a positive is defined as a RFC containing an IPv4 dependency, regardless of context.
在本次统计调查中，阳性定义为包含IPv4依赖项的RFC，而不考虑上下文。
In the initial survey of RFCs, 34 positives were identified out of a total of 257, broken down as follows:
在对RFC的初步调查中，在总共257个样本中发现了34个阳性样本，细分如下：
Standards: 1 out of 20 or 5.00% Draft Standards: 4 out of 25 or 16.00% Proposed Standards: 19 out of 155 or 12.26% Experimental RFCs: 10 out of 57 or 17.54%
标准：20分之一或5.00%标准草案：25分之四或16.00%拟定标准：155分之19或12.26%试验性RFC：57分之10或17.54%
For more information, please look at [1].
有关更多信息，请参阅[1]。
In the initial survey of RFCs, 52 positives were identified out of a total of 186, broken down as follows:
在RFC的初步调查中，在总共186个样本中，发现了52个阳性样本，细分如下：
Standards: 17 out of 24 or 70.83% Draft Standards: 6 out of 20 or 30.00% Proposed Standards: 22 out of 111 or 19.91% Experimental RFCs: 7 out of 31 or 22.58%
标准：24项标准中的17项或70.83%标准草案：20项标准中的6项或30.00%拟定标准：111项标准中的22项或19.91%实验性RFC：31项标准中的7项或22.58%
For more information, please look at [2].
有关更多信息，请参阅[2]。
In the initial survey of RFCs, 36 positives were identified out of a total of 153, broken down as follows:
在对RFC的初步调查中，在总共153个样本中确定了36个阳性样本，细分如下：
Standards: 6 out of 15 or 40.00% Draft Standards: 4 out of 15 or 26.67% Proposed Standards: 26 out of 112 or 23.21% Experimental RFCs: 0 out of 11 or 0.00%
标准：15分之6或40.00%标准草案：15分之4或26.67%拟定标准：112分之26或23.21%实验性RFC：11分之0或0.00%
For more information, please look at [3].
有关更多信息，请参阅[3]。
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%
For more information, please look at [4].
有关更多信息，请参阅[4]。
In the initial survey of RFCs, 4 positives were identified out of a total of 124, broken down as follows:
在RFC的初步调查中，在总共124个样本中，发现了4个阳性样本，细分如下：
Standards: 0 out of 1 or 0.00% Draft Standards: 1 out of 3 or 33.33% Proposed Standards: 1 out of 102 or 0.98% Experimental RFCs: 2 out of 18 or 11.11%
标准：0/1或0.00%标准草案：1/3或33.33%拟定标准：1/102或0.98%实验性RFC：2/18或11.11%
For more information, please look at [5].
有关更多信息，请参阅[5]。
In the initial survey of RFCs, 0 positives were identified out of a total of 7, broken down as follows:
在RFC的初始调查中，在总共7个样本中，确定了0个阳性样本，细分如下：
Standards: 0 out of 0 or 0.00% Draft Standards: 0 out of 0 or 0.00% Proposed Standards: 0 out of 6 or 0.00% Experimental RFCs: 0 out of 1 or 0.00%
标准：0分之0或0.00%标准草案：0分之0或0.00%建议标准：6分之0或0.00%实验RFC：1分之0或0.00%
For information about the Sub-IP Area standards, please look at [6].
有关子IP区域标准的信息，请参阅[6]。
In the initial survey of RFCs, 24 positives were identified out of a total of 104, broken down as follows:
在RFC的初步调查中，在总共104个样本中，发现了24个阳性样本，细分如下：
Standards: 3 out of 5 or 60.00% Draft Standards: 0 out of 2 or 0.00% Proposed Standards: 17 out of 82 or 20.73% Experimental RFCs: 4 out of 15 or 26.67%
标准：5分之3或60.00%标准草案：2分之0或0.00%建议标准：82分之17或20.73%实验性RFC：15分之4或26.67%
For more information, please look at [7].
有关更多信息，请参阅[7]。
In attempting this analysis, it was determined that a full scale analysis is well beyond the scope of this document. Instead, a short discussion is presented on how such a framework might be established.
在尝试该分析时，确定全面分析远远超出了本文件的范围。相反，就如何建立这样一个框架进行了简短的讨论。
A suggested approach would be to do an analysis of protocols based on their overall function, similar (but not strictly) to the OSI network reference model. It might be more appropriate to frame the discussion in terms of the different Areas of the IETF.
一种建议的方法是根据协议的总体功能对其进行分析，类似于（但不是严格地）OSI网络参考模型。根据IETF的不同领域来组织讨论可能更合适。
The problem is fundamental to the overall architecture of the Internet and its future. One of the stated goals of the IPng (now IPv6) was "automatic" and "easy" address renumbering. An additional goal is "stateless autoconfiguration." To these ends, a substantial amount of work has gone into the development of such protocols as DHCP and Dynamic DNS. This goes against the Internet age-old "end-to-end principle."
这个问题是互联网整体架构及其未来的基础。IPng（现在的IPv6）的一个既定目标是“自动”和“轻松”地址重新编号。另外一个目标是“无状态自动配置”。为此，大量工作已经投入到DHCP和动态DNS等协议的开发中。这与互联网由来已久的“端到端原则”背道而驰
Most protocol designs implicitly count on certain underlying principles that currently exist in the network. For example, the design of packet switched networks allows upper level protocols to ignore the underlying stability of packet routes. When paths change in the network, the higher level protocols are typically unaware and uncaring. This works well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of little consequence.
大多数协议设计隐含地依赖于网络中当前存在的某些基本原则。例如，分组交换网络的设计允许上层协议忽略分组路由的潜在稳定性。当网络中的路径发生变化时，较高级别的协议通常不知道也不关心。这很有效，因为无论数据包是去A-B-C-D-E-F还是去A-B-X-Y-Z-E-F都无关紧要。
In a world where endpoints (i.e., A and F in the example above) change at a "rapid" rate, a new model for protocol developers should be considered. It seems that a logical development would be a change in the operation of the Transport layer protocols. The current model is essentially a choice between TCP and UDP, neither of which provides any mechanism for an orderly handoff of the connection if and when the network endpoint (IP) addresses change. Perhaps a third
在端点（即上面示例中的a和F）以“快速”速率变化的世界中，应该考虑协议开发人员的新模型。从逻辑上看，传输层协议的操作将发生变化。当前的模型本质上是TCP和UDP之间的选择，两者都不提供在网络端点（IP）地址发生变化时有序切换连接的机制。也许是第三个
major transport layer protocol should be developed, or perhaps updated TCP and UDP specifications that include this function might be a better solution.
应该开发主要的传输层协议，或者更新包含此功能的TCP和UDP规范可能是更好的解决方案。
There are many, many variables that would need to go into a successful development of such a protocol. Some issues to consider are: timing principles; overlap periods as an endpoint moves from address A, to addresses A and B (answers to both), to only B; delays due to the recalculation of routing paths, etc...
要成功开发这样一个协议，需要很多很多的变量。需要考虑的几个问题是：时间原则；当端点从地址A移动到地址A和地址B（两者都有答案）再移动到仅B时，重叠周期；由于重新计算路由路径等导致的延迟。。。
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
本备忘录审查了规范的IPv6准备情况；这本身没有安全考虑。
The authors would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally the author, Philip J. Nesser II, would like to thanks his partner in all ways, Wendy M. Nesser.
作者希望感谢互联网协会在本文件的研究和制作过程中提供的支持。此外，作者Philip J.Nesser II想感谢他的合作伙伴Wendy M.Nesser。
The editor, Andreas Bergstrom, would like to thank Pekka Savola for guidance and collection of comments for the editing of this document. He would further like to thank Alan E. Beard, Jim Bound, Brian Carpenter, and Itojun for valuable feedback on many points of this document.
编辑Andreas Bergstrom感谢Pekka Savola为本文件的编辑提供指导和收集意见。他还要感谢Alan E.Beard、Jim Bound、Brian Carpenter和Itojun就本文件的许多要点提供了宝贵的反馈。
[1] Sofia, R. and P. Nesser, II, "Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards", RFC 3795, June 2004.
[1] Sofia，R.和P.Nesser，II，“当前部署的IETF应用领域标准中IPv4地址的调查”，RFC 3795，2004年6月。
[2] Mickles, C., Editor and P. Nesser, II, "Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards", RFC 3790, June 2004.
[2] Mickles，C.，编辑和P.Nesser，II，“当前部署的IETF互联网区域标准中IPv4地址的调查”，RFC 37902004年6月。
[3] Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards", RFC 3796, June 2004.
[3] Nesser，II，P.和A.Bergstrom，编辑，“当前部署的IETF运营和管理领域标准中IPv4地址的调查”，RFC 37962004年6月。
[4] Olvera, C. and P. Nesser, II, "Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards", RFC 3791, June 2004.
[4] Olvera，C.和P.Nesser，II，“当前部署的IETF路由区域标准中IPv4地址的调查”，RFC 37912004年6月。
[5] Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards", RFC 3792, June 2004.
[5] Nesser，II，P.和A.Bergstrom，编辑，“当前部署的IETF安全区域标准中IPv4地址的调查”，RFC 3792，2004年6月。
[6] Nesser, II, P. and A. Bergstrom, Editor, "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 3793，2004年6月。
[7] Nesser, II, P. and A. Bergstrom, Editor, "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月。
Please contact the authors with any questions, comments or suggestions at:
如有任何问题、意见或建议，请联系作者：
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
Fax: +1 425 482 9721
EMail: phil@nesser.com
Phone: +1 425 481 4303
Fax: +1 425 482 9721
EMail: phil@nesser.com
Andreas Bergstrom, Editor Ostfold University College Rute 503 Buer N-1766 Halden Norway
Andreas Bergstrom，编辑奥斯特福德大学学院Rute 503 Buer N-1766挪威哈尔登
EMail: andreas.bergstrom@hiof.no
EMail: andreas.bergstrom@hiof.no
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编辑功能的资金目前由互联网协会提供。