Network Working Group P. Nesser, II
Request for Comments: 3792 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Network Working Group P. Nesser, II
Request for Comments: 3792 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Security 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 document seeks to document all usage of IPv4 addresses in currently deployed IETF Security 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 Organisation. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 2
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 8
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 20
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . . 23
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . . 23
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organisation. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 2
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 8
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 20
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . . 23
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . . 23
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. Normative Reference. . . . . . . . . . . . . . . . . . . . . . 24
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
10. Normative Reference. . . . . . . . . . . . . . . . . . . . . . 24
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
This document is part of 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, Internet, Operations and Management, Routing, Security, Sub-IP, and Transport).
本文档是旨在记录IETF标准中IPv4地址的所有使用情况的文档集的一部分。为了使信息具有可管理的形式，已将其分为符合当前IETF领域（应用、互联网、操作和管理、路由、安全、子IP和传输）的7个文档。
For a full introduction, please see the introduction [1].
有关完整的介绍，请参见介绍[1]。
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, and Proposed Standards, and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending with (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.
完整的互联网标准（通常简称为“标准”）是在整个互联网上广泛实施和使用的完全成熟的协议规范。
There are no IPv4 dependencies in this specification.
此规范中不存在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中倒数第二个标准级别。只有当存在多个独立的、可互操作的实现时，协议才能实现标准草案。标准草案通常是相当成熟和广泛使用的。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.2. RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
4.2. RFC 2617 HTTP身份验证：基本和摘要访问身份验证
Section 3.2.1 The WWW-Authenticate Response Header include he following text:
第3.2.1节WWW认证响应标题包括以下文本：
(Note: including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that originally got it. However, that would break proxy farms, where requests from a single user often go through different proxies in the farm. Also, IP address spoofing is not that hard.)
（注意：将客户机的IP地址包含在nonce中似乎可以让服务器将nonce的重用限制在最初获得它的同一客户机上。但是，这会破坏代理服务器场，其中来自单个用户的请求通常通过服务器场中的不同代理。此外，IP地址欺骗也不是那么难。）
Section 4.5 Replay Attacks contains the text:
第4.5节重播攻击包含以下内容：
Thus, for some purposes, it is necessary to protect against replay attacks. A good Digest implementation can do this in various ways. The server created "nonce" value is implementation dependent, but if it contains a digest of the client IP, a time-stamp, the resource ETag, and a private server key (as recommended above) then a replay attack is not simple. An attacker must convince the server that the request is coming from a false IP address and must cause the server to deliver the document to an IP address different from the address to which it believes it is sending the document. An attack can only succeed in the period before the time-stamp expires. Digesting the client IP and time-stamp in the nonce permits an implementation which does not maintain state between transactions.
因此，出于某些目的，有必要防止重播攻击。一个好的摘要实现可以通过多种方式实现这一点。服务器创建的“nonce”值取决于实现，但如果它包含客户端IP摘要、时间戳、资源ETag和专用服务器密钥（如上所述），则重播攻击并不简单。攻击者必须使服务器确信请求来自错误的IP地址，并且必须使服务器将文档发送到与其认为要将文档发送到的地址不同的IP地址。攻击只能在时间戳过期之前成功。在nonce中消化客户机IP和时间戳允许不维护事务之间状态的实现。
Both of these statements are IP version independent and must rely on the implementers discretion.
这两个语句都是独立于IP版本的，必须依赖于实现者的判断。
Section 3. Packet Format has the following notes:
第3节。数据包格式有以下注释：
Identifier
标识符
The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time.
标识符字段是一个八位字节，有助于匹配请求和响应。如果RADIUS服务器在短时间内具有相同的客户端源IP地址、源UDP端口和标识符，则RADIUS服务器可以检测到重复请求。
and
和
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
RADIUS服务器必须使用RADIUS UDP数据包的源IP地址来决定使用哪个共享密钥，以便可以代理RADIUS请求。
This text is version neutral but implementers should allow for the use of both IPv4 and IPv6 addresses.
此文本与版本无关，但实现者应允许同时使用IPv4和IPv6地址。
Section 5. Attributes defines a number of IP specific attributes:
第5节。属性定义了许多特定于IP的属性：
4 NAS-IP-Address 8 Framed-IP-Address 9 Framed-IP-Netmask 10 Framed-Routing 14 Login-IP-Host 22 Framed-Route
4 NAS IP地址8帧IP地址9帧IP网络掩码10帧路由14登录IP主机22帧路由
and definitions for the "value" field of the following type:
以及以下类型的“值”字段的定义：
address 32 bit value, most significant octet first.
地址32位值，最重要的八位位组在前。
The attributes are further defined as follows:
属性进一步定义如下：
5.4. NAS-IP-Address
5.4. NAS IP地址
Description
描述
This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP-Address is only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier MUST be present in an Access-Request packet.
此属性表示正在请求用户身份验证的NAS的标识IP地址，并且对于RADIUS服务器范围内的NAS来说应该是唯一的。NAS IP地址仅用于访问请求数据包。NAS IP地址或NAS标识符必须存在于访问请求数据包中。
Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret.
请注意，NAS IP地址不得用于选择用于验证请求的共享机密。访问请求数据包的源IP地址必须用于选择共享密钥。
A summary of the NAS-IP-Address Attribute format is shown below. The fields are transmitted from left to right.
NAS IP地址属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
4 for NAS-IP-Address.
4表示NAS IP地址。
Length
长
6
6.
Address
住址
The Address field is four octets.
地址字段是四个八位字节。
5.8. Framed-IP-Address
5.8. 框架IP地址
Description
描述
This Attribute indicates the address to be configured for the user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint.
此属性表示要为用户配置的地址。它可以用于访问和接受数据包。它可以在访问请求数据包中用作NAS向服务器发出的提示，表示它更喜欢该地址，但服务器不需要遵守该提示。
A summary of the Framed-IP-Address Attribute format is shown below. The fields are transmitted from left to right.
框架IP地址属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
8 for Framed-IP-Address.
8表示框架IP地址。
Length
长
6
6.
Address
住址
The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS Should allow the user to select an address (e.g., Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g., Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address.
地址字段是四个八位字节。值0xFFFFFF表示NAS应允许用户选择地址（例如，协商）。值0xFFFFFE表示NAS应为用户选择一个地址（例如，从NAS保留的地址池中分配）。其他有效值指示NAS应将该值用作用户的IP地址。
5.9. Framed-IP-Netmask
5.9. 框架式IP网络掩码
Description
描述
This Attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint.
此属性表示当用户是网络路由器时，要为其配置的IP网络掩码。它可以用于访问和接受数据包。它可以在访问请求数据包中用作NAS向服务器发出的提示，表示它希望使用该网络掩码，但服务器不需要遵守该提示。
A summary of the Framed-IP-Netmask Attribute format is shown below. The fields are transmitted from left to right.
框架IP网络掩码属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
9 for Framed-IP-Netmask.
9用于帧式IP网络掩码。
Length
长
6
6.
Address
住址
The Address field is four octets specifying the IP netmask of the user.
地址字段是四个八位字节，用于指定用户的IP网络掩码。
5.14. Login-IP-Host
5.14. 登录IP主机
Description
描述
"This Attribute indicates the system with which to connect the user, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint."
此属性表示在包含“登录服务”属性时与用户连接的系统。它可用于访问接受数据包中。它可用于访问请求数据包中，作为NAS希望使用该主机的服务器提示，但服务器无需遵守此提示
A summary of the Login-IP-Host Attribute format is shown below. The fields are transmitted from left to right.
登录IP主机属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
14 for Login-IP-Host.
14用于登录IP主机。
Length
长
6
6.
Address
住址
The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to select an address. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address the NAS SHOULD connect the user to.
地址字段是四个八位字节。值0xFFFFFF表示NAS应允许用户选择地址。值0表示NAS应选择要将用户连接到的主机。其他值指示NAS应将用户连接到的地址。
5.22. Framed-Route
5.22. 框架路线
Description
描述
This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times.
此属性提供要在NAS上为用户配置的路由信息。它用于Access Accept数据包中，可以多次出现。
A summary of the Framed-Route Attribute format is shown below. The fields are transmitted from left to right.
框架布线属性格式的摘要如下所示。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
类型
22 for Framed-Route.
22为框架路线。
Length
长
>= 3
>= 3
Text
文本
The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters.
文本字段是一个或多个八位字节，其内容取决于实现。其目的是让人可读，并且不得影响协议的运行。建议消息包含UTF-8编码的10646[7]个字符。
For IP routes, it SHOULD contain a destination prefix in dotted quad form optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address in dotted quad form, a space, and one or more metrics separated by spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length specifier may be omitted, in which case it defaults to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
对于IP路由，它应该包含一个虚线四元组形式的目的地前缀，可选地后跟一个斜杠和一个十进制长度说明符，说明要使用的前缀的高阶位数。后面是一个空格、一个虚线四元形式的网关地址、一个空格和一个或多个由空格分隔的度量。例如，“192.168.1.0/24192.168.1.112400”。长度说明符可以省略，在这种情况下，A类前缀默认为8位，B类前缀默认为16位，C类前缀默认为24位。例如，“192.168.1.0 192.168.1.1 1”。
Whenever the gateway address is specified as "0.0.0.0" the IP address of the user SHOULD be used as the gateway address.
当网关地址被指定为“0.0.0.0”时，应将用户的IP地址用作网关地址。
There are also several example authentication sequences that use the attributes discussed above and hence have IPv4 addresses.
还有几个示例身份验证序列使用上面讨论的属性，因此具有IPv4地址。
Although the definitions in this RFC are limited to IPv4 addresses, the specification is easily extensible for new attribute types. It is therefore relatively simple to create new IPv6 specific attributes.
尽管此RFC中的定义仅限于IPv4地址，但该规范对于新的属性类型很容易扩展。因此，创建新的IPv6特定属性相对简单。
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
拟议标准是介绍性文件。即使是单个实现也没有要求。在许多情况下，在IETF标准过程中从未实施或推进提议。因此，它们通常只是被提出的想法
presented to the Internet community. Sometimes flaws are exposed or 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.001. RFC 1413 Identification Protocol
5.001. RFC1413识别协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.002. RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I
5.002. RFC 1421互联网电子邮件隐私增强：第一部分
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.003. RFC 1422 Privacy Enhancement for Internet Electronic Mail: Part II
5.003. RFC 1422互联网电子邮件隐私增强：第二部分
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.004. RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III
5.004. RFC 1423互联网电子邮件隐私增强：第三部分
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.005. RFC 1424 Privacy Enhancement for Internet Electronic Mail: Part IV
5.005. RFC 1424互联网电子邮件隐私增强：第四部分
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.006. RFC 1510 The Kerberos Network Authentication Service (V5)
5.006. RFC 1510 Kerberos网络身份验证服务（V5）
Although this specification specifies optional use of host addresses, there are no specific requirements that the addresses be IPv4. The specification has no IPv4 dependencies, but implementations might have issues.
尽管本规范规定了主机地址的可选使用，但没有关于地址为IPv4的具体要求。该规范没有IPv4依赖项，但实现可能存在问题。
5.007. RFC 1731 IMAP4 Authentication Mechanisms
5.007. RFC 1731 IMAP4身份验证机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.008. RFC 1734 POP3 AUTHentication command
5.008. RFC 1734 POP3身份验证命令
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.009. RFC 1828 IP Authentication using Keyed MD5
5.009. 使用密钥MD5的RFC 1828 IP身份验证
There are no IPv4 dependencies in this specification. The operations described operate on the entire IP packet without specifying that the IP packet be IPv4 or IPv6.
此规范中不存在IPv4依赖项。所描述的操作对整个IP数据包进行操作，而不指定IP数据包是IPv4或IPv6。
5.010. RFC 1829 The ESP DES-CBC Transform
5.010. RFC1829 ESP DES-CBC变换
There are no IPv4 dependencies in this specification. The operations described operate on the entire IP packet without specifying that the IP packet be IPv4 or IPv6.
此规范中不存在IPv4依赖项。所描述的操作对整个IP数据包进行操作，而不指定IP数据包是IPv4或IPv6。
5.011. RFC 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
5.011. RFC 1847 MIME安全多部分：多部分/签名和多部分/加密
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.012. RFC 1848 MIME Object Security Services
5.012. RFC 1848 MIME对象安全服务
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.013. RFC 1928 SOCKS Protocol Version
5.013. RFC1928 SOCKS协议版本
This specification is IPv6 aware and will function normally on either IPv4 and IPv6.
此规范支持IPv6，将在IPv4和IPv6上正常运行。
5.014. RFC 1929 Username/Password Authentication for SOCKS V5
5.014. RFC 1929 SOCKS V5的用户名/密码身份验证
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.015. RFC 1961 GSS-API Authentication Method for SOCKS Version 5
5.015. SOCKS版本5的RFC 1961 GSS-API认证方法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.016. RFC 1964 The Kerberos Version 5 GSS-API Mechanism
5.016. RFC1964 Kerberos版本5 GSS-API机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.017. RFC 1968 The PPP Encryption Control Protocol (ECP)
5.017. RFC 1968 PPP加密控制协议（ECP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.018. RFC 2015 MIME Security with Pretty Good Privacy (PGP)
5.018. RFC 2015 MIME安全性与相当好的隐私（PGP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.019. RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM)
5.019. RFC 2025简单公钥GSS-API机制（SPKM）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.020. RFC 2082 RIP-2 MD5 Authentication
5.020. RFC 2082 RIP-2 MD5身份验证
This RFC documents a security mechanism for an IPv4 only routing specification. It is expected that a similar (or better) mechanism will be developed for RIPng.
此RFC记录了仅IPv4路由规范的安全机制。预计将为RIPng开发类似（或更好）的机制。
5.021. RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention
5.021. RFC 2085 HMAC-MD5 IP身份验证，具有防重播功能
This document defines an IP version independent specification and has no IPv4 dependencies.
本文档定义了一个独立于IP版本的规范，并且没有IPv4依赖项。
5.022. RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/ Response
5.022. RFC 2195 IMAP/POP授权扩展，用于简单质询/响应
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.023. RFC 2203 RPCSEC_GSS Protocol Specification
5.023. RFC 2203 RPCSEC_GSS协议规范
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.024. RFC 2222 Simple Authentication and Security Layer (SASL)
5.024. RFC 2222简单身份验证和安全层（SASL）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.025. RFC 2228 FTP Security Extensions
5.025. RFC 2228 FTP安全扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.026. RFC 2243 OTP Extended Responses
5.026. RFC 2243 OTP扩展响应
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.027. RFC 2245 Anonymous SASL Mechanism
5.027. RFC 2245匿名SASL机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.028. RFC 2246 The TLS Protocol Version 1.0
5.028. RFC 2246 TLS协议版本1.0
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.029. RFC 2284 PPP Extensible Authentication Protocol (EAP)
5.029. RFC 2284 PPP可扩展认证协议（EAP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.030. RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option
5.030. RFC 2385通过TCP MD5签名选项保护BGP会话
Although the specification enhancements have no IPv4 dependencies, it is an update to an IPv4 only routing specification.
尽管规范增强没有IPv4依赖项，但它是对仅IPv4路由规范的更新。
5.031. RFC 2401 Security Architecture for the Internet Protocol
5.031. 互联网协议的RFC 2401安全体系结构
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.032. RFC 2402 IP Authentication Header
5.032. RFC 2402 IP认证头
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.033. RFC 2403 The Use of HMAC-MD5-96 within ESP and AH
5.033. RFC 2403在ESP和AH中使用HMAC-MD5-96
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.034. RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH
5.034. RFC 2404在ESP和AH中使用HMAC-SHA-1-96
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.035. RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
5.035. RFC 2405带显式IV的ESP DES-CBC密码算法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.036. RFC 2406 IP Encapsulating Security Payload (ESP)
5.036. RFC 2406 IP封装安全有效负载（ESP）
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.037. RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP
5.037. RFC 2407 ISAKMP解释的Internet IP安全域
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.038. RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)
5.038. RFC 2408互联网安全关联和密钥管理协议（ISAKMP）
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.039. RFC 2409 The Internet Key Exchange (IKE)
5.039. RFC 2409因特网密钥交换（IKE）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.040. RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec
5.040. RFC 2410空加密算法及其在IPsec中的应用
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.041. RFC 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis)
5.041. RFC 2419 PPP DES加密协议，第2版（DESE bis）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.042. RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE)
5.042. RFC 2420 PPP三重DES加密协议（3DESE）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.043. RFC 2440 OpenPGP Message Format
5.043. RFC 2440 OpenPGP消息格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.044. RFC 2444 The One-Time-Password SASL Mechanism
5.044. RFC 2444一次性密码SASL机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.045. RFC 2451 The ESP CBC-Mode Cipher Algorithms
5.045. RFC 2451 ESP CBC模式密码算法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.046. RFC 2478 The Simple and Protected GSS-API Negotiation Mechanism
5.046. RFC 2478简单且受保护的GSS-API协商机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.047. RFC 2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols
5.047. RFC 2510 Internet X.509公钥基础结构证书管理协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.048. RFC 2511 Internet X.509 Certificate Request Message Format
5.048. RFC 2511 Internet X.509证书请求消息格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.049. RFC 2535 Domain Name System Security Extensions
5.049. RFC 2535域名系统安全扩展
There are no IPv4 dependencies in this specification. There are discussions of A and AAAA records in the document, but have no real implications on IPv4 dependency or on any IP related address records.
此规范中不存在IPv4依赖项。文档中讨论了A和AAAA记录，但对IPv4依赖关系或任何与IP相关的地址记录没有实际影响。
5.050. RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS)
5.050. 域名系统（DNS）中的RFC 2536 DSA密钥和SIG
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.051. RFC 2538 Storing Certificates in the Domain Name System (DNS)
5.051. RFC 2538在域名系统（DNS）中存储证书
Section 3.1 X.509 CERT RR Names
第3.1节X.509证书RR名称
Some X.509 versions permit multiple names to be associated with subjects and issuers under "Subject Alternate Name" and "Issuer Alternate Name". For example, x.509v3 has such Alternate Names with an ASN.1 specification as follows:
某些X.509版本允许在“受试者备选名称”和“发行人备选名称”下与受试者和发行人关联多个名称。例如，x.509v3具有以下具有ASN.1规范的备用名称：
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] EXPLICIT OR-ADDRESS.&Type,
directoryName [4] EXPLICIT Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER
}
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] EXPLICIT OR-ADDRESS.&Type,
directoryName [4] EXPLICIT Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER
}
uses a potential IPv4 only address. It goes on with the following example:
使用可能的仅IPv4地址。下面是一个例子：
Example 2: Assume that an X.509v3 certificate is issued to /CN=James Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and (c) string "James Hacker <hacker@mail.widget.foo.example>". Then the storage locations recommended, in priority order, would be (1) widget.foo.example, (2) 201.13.251.10.in-addr.arpa, and (3) hacker.mail.widget.foo.example.
示例2：假设向/CN=James Hacker/L=Basingstoke/O=Widget Inc/C=GB/颁发了一份X.509v3证书，证书的主题替换名为（a）域名Widget.foo.Example，（b）IPv4地址10.251.13.201，（C）字符串“James Hacker”<hacker@mail.widget.foo.example>". 然后，建议的存储位置按优先级顺序为（1）widget.foo.example、（2）201.13.251.10.in-addr.arpa和（3）hacker.mail.widget.foo.example。
Since the definition of X.509v3 certificates is not discussed in this document it is unclear if IPv6 addresses are also supported in the above mentioned field. The document does however refer to RFC 2459 for the definition of a certificate, and RFC 2459 is IPv6 and IPv4 aware -- so it seems this specification is IPv4 and IPv6 aware.
由于本文档未讨论X.509v3证书的定义，因此不清楚上述字段是否也支持IPv6地址。然而，该文档确实参考了RFC 2459以获取证书的定义，并且RFC 2459支持IPv6和IPv4，因此该规范似乎支持IPv4和IPv6。
5.052. RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
5.052. RFC 2539域名系统（DNS）中Diffie-Hellman密钥的存储
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.053. RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Specification - OCSP
5.053. RFC 2560 X.509 Internet公钥基础设施联机证书状态规范-OCSP
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.054. RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
5.054. RFC 2585 Internet X.509公钥基础设施操作协议：FTP和HTTP
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.055. RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema
5.055. RFC 2587 Internet X.509公钥基础结构LDAPv2架构
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.056. RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
5.056. RFC 2623 NFS版本2和版本3的安全问题以及NFS协议对RPCSEC_GSS和Kerberos V5的使用
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.057. RFC 2631 Diffie-Hellman Key Agreement Method
5.057. RFC 2631 Diffie-Hellman密钥协商方法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.058. RFC 2632 S/MIME Version 3 Certificate Handling
5.058. RFC 2632 S/MIME版本3证书处理
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.059. RFC 2633 S/MIME Version 3 Message Specification
5.059. RFC 2633 S/MIME版本3消息规范
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.060. RFC 2634 Enhanced Security Services for S/MIME
5.060. RFC 2634增强的S/MIME安全服务
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.061. RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
5.061. RFC 2712将Kerberos密码套件添加到传输层安全性（TLS）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.062. RFC 2743 Generic Security Service Application Program Interface Version 2 Update 1
5.062. RFC 2743通用安全服务应用程序接口版本2更新1
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.063. RFC 2744 Generic Security Service API Version 2: C-bindings
5.063. RFC 2744通用安全服务API第2版：C绑定
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.064. RFC 2747 RSVP Cryptographic Authentication
5.064. RFC 2747 RSVP加密身份验证
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.065. RFC 2797 Certificate Management Messages over CMS
5.065. CMS上的RFC 2797证书管理消息
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.066. RFC 2817 Upgrading to TLS Within HTTP/1.1
5.066. RFC 2817在HTTP/1.1中升级到TLS
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.067. RFC 2829 Authentication Methods for LDAP
5.067. RFC 2829 LDAP的身份验证方法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.068. RFC 2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security (LDAP)
5.068. RFC 2830轻型目录访问协议（v3）：传输层安全性（LDAP）扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.069. RFC 2831 Using Digest Authentication as a SASL Mechanism
5.069. RFC 2831使用摘要身份验证作为SASL机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.070. RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
5.070. RFC 2845 DNS密钥事务验证（TSIG）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.071. RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
5.071. RFC 2847 LIPKEY-使用SPKM的低基础结构公钥机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.072. RFC 2853 Generic Security Service API Version 2 : Java Bindings
5.072. RFC 2853通用安全服务API第2版：Java绑定
The document uses the InetAddress variable which does not necessarily limit it to IPv4 addresses so there are no IPv4 dependencies in this specification.
文档使用InetAddress变量，该变量不一定将其限制为IPv4地址，因此本规范中不存在IPv4依赖项。
5.073. RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH
5.073. RFC 2857在ESP和AH中使用HMAC-RIPEMD-160-96
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.074. RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms
5.074. RFC 2875 Diffie-Hellman占有算法证明
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.075. RFC 2930 Secret Key Establishment for DNS (TKEY RR)
5.075. RFC 2930 DNS密钥建立（TKEY RR）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.076. RFC 2931 DNS Request and Transaction Signatures (SIG(0)s)
5.076. RFC 2931 DNS请求和事务签名（SIG（0）s）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.077. RFC 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement
5.077. RFC 2935互联网开放交易协议（IOTP）HTTP补充
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.078. RFC 2941 Telnet Authentication Option
5.078. RFC 2941远程登录验证选项
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.079. RFC 2942 Telnet Authentication: Kerberos Version 5
5.079. RFC 2942 Telnet身份验证：Kerberos版本5
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.080. RFC 2943 TELNET Authentication Using DSA
5.080. RFC 2943使用DSA的TELNET身份验证
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.081. RFC 2944 Telnet Authentication: SRP
5.081. RFC 2944 Telnet身份验证：SRP
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.082. RFC 2945 The SRP Authentication and Key Exchange System
5.082. RFC 2945 SRP认证和密钥交换系统
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.083. RFC 2946 Telnet Data Encryption Option
5.083. RFC 2946 Telnet数据加密选项
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.084. RFC 2947 Telnet Encryption: DES3 64 bit Cipher Feedback
5.084. RFC 2947 Telnet加密：DES3 64位密码反馈
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.085. RFC 2948 Telnet Encryption: DES3 64 bit Output Feedback
5.085. RFC 2948 Telnet加密：DES3 64位输出反馈
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.086. RFC 2949 Telnet Encryption: CAST-128 64 bit Output Feedback
5.086. RFC 2949 Telnet加密：CAST-128 64位输出反馈
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.087. RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback
5.087. RFC 2950 Telnet加密：CAST-128 64位密码反馈
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.088. RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS
5.088. RFC 2984在CMS中使用CAST-128加密算法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.089. RFC 3007 Secure Domain Name System (DNS) Dynamic Update
5.089. RFC 3007安全域名系统（DNS）动态更新
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.090. RFC 3008 Domain Name System Security (DNSSEC) Signing Authority
5.090. RFC 3008域名系统安全（DNSSEC）签名机构
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.091. RFC 3012 Mobile IPv4 Challenge/Response Extensions
5.091. RFC 3012移动IPv4质询/响应扩展
This document is specifically designed for IPv4.
本文档专为IPv4设计。
5.092. RFC 3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile
5.092. RFC 3039 Internet X.509公钥基础结构合格证书配置文件
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.093. RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
5.093. 用于IPv6中无状态地址自动配置的RFC 3041隐私扩展
This is an IPv6 related document and is not discussed in this document.
这是一份与IPv6相关的文档，本文档中没有讨论。
5.094. RFC 3062 LDAP Password Modify Extended Operation
5.094. RFC 3062 LDAP密码修改扩展操作
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.095. RFC 3090 DNS Security Extension Clarification on Zone Status
5.095. 关于区域状态的RFC 3090 DNS安全扩展说明
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.096. RFC 3097 RSVP Cryptographic Authentication -- Updated Message Type Value
5.096. RFC 3097 RSVP加密身份验证--更新的消息类型值
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.097. RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
5.097. RFC 3110域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.098. RFC 3118 Authentication for DHCP Messages
5.098. RFC 3118 DHCP消息的身份验证
This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6.
此文档仅指定用于IPv4。预计DHCPv6中也会提供类似的功能。
5.099. RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security
5.099. RFC 3207 SMTP服务扩展，用于传输层安全SMTP
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.100. RFC 3275 (Extensible Markup Language) XML-Signature Syntax and Processing
5.100. RFC 3275（可扩展标记语言）XML签名语法和处理
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.101. RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
5.101. RFC 3280 Internet X.509公钥基础结构证书和证书吊销列表（CRL）配置文件
This specification is IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.102. RFC 3369 Cryptographic Message Syntax (CMS)
5.102. RFC 3369加密消息语法（CMS）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Experimental RFCs typically define protocols that do not have widescale 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上没有大规模实现或使用的协议。它们通常在性质上是恰当的，或者在有限的领域中使用。为了允许潜在的互操作性或其他一些潜在的有用场景，它们被记录到互联网社区中。在少数情况下，它们被作为主流解决方案的替代方案来解决一个公认的问题。
6.01. RFC 1004 Distributed-protocol authentication scheme
6.01. rfc1004分布式协议认证方案
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.02. RFC 1411 Telnet Authentication: Kerberos Version 4
6.02. RFC 1411 Telnet身份验证：Kerberos版本4
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.03. RFC 1412 Telnet Authentication: SPX
6.03. RFC 1412 Telnet身份验证：SPX
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.04. RFC 1507 DASS - Distributed Authentication Security Service
6.04. RFC 1507 DASS-分布式身份验证安全服务
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.05. RFC 1851 The ESP Triple DES Transform
6.05. RFC1851 ESP三重DES变换
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.06. RFC 1949 Scalable Multicast Key Distribution (SMKD)
6.06. RFC 1949可扩展多播密钥分发（SMKD）
This specification assumes the use of IGMP and is therefore limited to IPv4 multicast. It is assumed that a similar mechanism may be defined for IPv6 multicasting.
本规范假定使用IGMP，因此仅限于IPv4多播。假设可以为IPv6多播定义类似的机制。
6.07. RFC 2093 Group Key Management Protocol (GKMP) Specification
6.07. RFC 2093组密钥管理协议（GKPP）规范
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.08. RFC 2094 Group Key Management Protocol (GKMP) Architecture
6.08. RFC 2094组密钥管理协议（GKPP）体系结构
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.09. RFC 2154 OSPF with Digital Signatures
6.09. 带数字签名的RFC 2154 OSPF
This OSPF option is IPv4 limited. See the following packet format:
此OSPF选项受IPv4限制。请参阅以下数据包格式：
7.2. Router Public Key Certificate
7.2. 路由器公钥证书
A router public key certificate is a package of data signed by a Trusted Entity. This certificate is included in the router PKLSA and in the router configuration information. To change any of the values in the certificate, a new certificate must be obtained from a TE.
路由器公钥证书是由可信实体签名的数据包。此证书包含在路由器PKLSA和路由器配置信息中。要更改证书中的任何值，必须从TE获得新证书。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Router Id |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| TE Id | TE Key Id | Rtr Key Id | Sig Alg |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Create Time |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Key Field Length | Router Role | #Net Ranges |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Address Mask |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| IP Address/Address Mask for each Net Range ... /
| ... /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Router Public Key |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Certification /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Router Id |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| TE Id | TE Key Id | Rtr Key Id | Sig Alg |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Create Time |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Key Field Length | Router Role | #Net Ranges |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Address Mask |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| IP Address/Address Mask for each Net Range ... /
| ... /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Router Public Key |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Certification /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
#NET RANGES The number of network ranges that follow. A network range is defined to be an IP Address and an Address Mask. This list of ranges defines the addresses that the Router is permitted to advertise in its Router Links LSA. Valid values are 0-255. If there are 0 ranges the router cannot advertise anything. This is not generally useful. One range with address=0 and mask=0 will allow a router to advertise any address.
#NET RANGES随后的网络范围数。网络范围定义为IP地址和地址掩码。此范围列表定义允许路由器在其路由器链路LSA中公布的地址。有效值为0-255。如果有0个范围，路由器无法播发任何内容。这通常不是有用的。一个地址为0且掩码为0的范围将允许路由器公布任何地址。
IP ADDRESS & ADDRESS MASK Define a range of addresses that this router may advertise. Each is a 32 bit value. One range with address=0 and mask=0 will allow a router to advertise any address.
IP地址和地址掩码定义此路由器可能公布的地址范围。每个都是一个32位的值。一个地址为0且掩码为0的范围将允许路由器公布任何地址。
6.10. RFC 2522 Photuris: Session-Key Management Protocol
6.10. RFC 2522 Photuris：会话密钥管理协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.11. RFC 2523 Photuris: Extended Schemes and Attributes
6.11. RFC 2523 Photuris：扩展方案和属性
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.12. RFC 2659 Security Extensions For HTML
6.12. RFC 2659 HTML安全扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.13. RFC 2660 The Secure HyperText Transfer Protocol
6.13. RFC 2660安全超文本传输协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.14. RFC 2692 SPKI Requirements
6.14. RFC 2692 SPKI要求
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.15. RFC 2693 SPKI Certificate Theory
6.15. RFC 2693 SPKI证书理论
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.16. RFC 2716 PPP EAP TLS Authentication Protocol
6.16. RFC 2716 PPP EAP TLS认证协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.17. RFC 2773 Encryption using KEA and SKIPJACK
6.17. 使用KEA和SKIPJACK的RFC 2773加密
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
6.18. RFC 3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols
6.18. RFC 3029 Internet X.509公钥基础结构数据验证和认证服务器协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
In the initial survey of RFCs 4 positives were identified out of a total of 124, broken down as follows:
在RFCs的初步调查中，在总共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%
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.
此外，还有许多应更新的标准实例，但如果不更新，则不会造成任何运营影响。其余实例记录如下。
7.2.1. RADIUS (RFC 2865)
7.2.1. 半径（RFC 2865）
The problems have been resolved in RFC 3162, RADIUS and IPv6.
这些问题已在RFC3162、RADIUS和IPv6中得到解决。
7.3.1. RIPv2 MD5 Authentication (RFC 2082)
7.3.1. RIPv2 MD5身份验证（RFC 2082）
This functionality has been assumed by the use of the IPsec AH header as defined in RFC 2402, IP Authentication Header.
通过使用RFC 2402“IP认证头”中定义的IPsec AH头，可以实现此功能。
7.3.2. Mobile IPv4 Challenge Response Extension (RFC 3012)
7.3.2. 移动IPv4质询响应扩展（RFC 3012）
The problems are not being addressed and similar functions may be needed in Mobile IPv6.
这些问题尚未得到解决，移动IPv6中可能需要类似的功能。
7.3.3. Authentication for DHCP Messages (RFC 3118)
7.3.3. DHCP消息的身份验证（RFC 3118）
This problem has been fixed in RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
RFC 3315，IPv6的动态主机配置协议（DHCPv6）中已修复了此问题。
7.4.1. Scalable Multicast Key Distribution (RFC 1949)
7.4.1. 可扩展多播密钥分发（RFC 1949）
This specification relies on IPv4 IGMP Multicast and a new specification may be produced; however, the SMKD is not believed to be in use.
该规范依赖于IPv4 IGMP多播，可能会产生新的规范；但是，据信SMKD未投入使用。
7.4.2. OPSF with Digital Signatures (RFC 2154)
7.4.2. 带有数字签名的OPSF（RFC 2154）
This specification is IPv4-only, and relies on an IPv4-only routing protocol, OSPFv2. Due to increased focus on routing security, this specification may need to be revisited, and in that case it should support both OSPFv2 and OPSFv3.
此规范仅适用于IPv4，并且依赖于仅适用于IPv4的路由协议OSPFv2。由于越来越关注路由安全性，可能需要重新访问此规范，在这种情况下，它应该同时支持OSPFv2和OPSFv3。
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.
编辑Andreas Bergstrom感谢Pekka Savola为本文件的编辑提供指导和收集意见。
[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月。
Please contact the author 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 48
EMail: phil@nesser.com
Phone: +1 425 481 4303
Fax: +1 425 48
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编辑功能的资金目前由互联网协会提供。