Network Working Group R. Sofia
Request for Comments: 3795 P. Nesser, II
Category: Informational Nesser & Nesser Consulting
June 2004
Network Working Group R. Sofia
Request for Comments: 3795 P. Nesser, II
Category: Informational Nesser & Nesser Consulting
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Application 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 describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6.
本文档描述了IPv4寻址依赖关系，旨在阐明重新设计和重新实施规范的必要步骤，使其成为网络地址独立的规范，或至少是双重支持IPv4和IPv6的规范。此转换需要几个临时步骤，其中之一是将当前的IPv4相关规范演变为独立于所用IP寻址模式类型的格式。因此，希望重新设计和实施规范，使其成为独立于网络地址的，或者至少双重支持IPv4和IPv6。
To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience.
为了实现这一步，有必要调查和记录当前标准（完整、草案和建议）以及实验性RFC所经历的所有IPv4依赖关系。因此，本文档描述了部署的IETF应用程序领域文档化标准可能遇到的IPv4寻址依赖关系。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 10
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 45
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References. . . . . . . . . . . . . . . . . . 48
10.2. Informative References. . . . . . . . . . . . . . . . . 48
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 50
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 10
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 45
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References. . . . . . . . . . . . . . . . . . 48
10.2. Informative References. . . . . . . . . . . . . . . . . 48
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 50
The exhaustive documentation of IPv4 addresses usage in currently deployed IETF documented standards has now been broken into seven documents conforming to current IETF main areas, i.e., Applications, Internet, Operations and Management, Routing, Sub-IP, and Transport. A general overview of the documentation, as well as followed methodology and historical perspective can be found in [1]. This document represents one of the seven blocks, and its scope is limited to surveying possible IPv4 dependencies in IETF Application Area documented Standards.
目前部署的IETF文件化标准中IPv4地址使用的详尽文档现已分为符合当前IETF主要领域的七个文档，即应用程序、互联网、操作和管理、路由、子IP和传输。文献综述以及遵循的方法和历史观点见[1]。本文档代表七个模块之一，其范围仅限于调查IETF应用领域文件化标准中可能存在的IPv4依赖关系。
The remainder sections are organized as follows. Sections 3, 4, 5, and 6 describe, respectively, the raw analysis of Internet Standards [2]:
其余部分的组织如下。第3、4、5和6节分别描述了互联网标准的原始分析[2]：
Full, Draft, and Proposed Standards, and Experimental RFCs. For each section, standards are analysed by their RFC number, in sequential order, i.e., from RFC 1 to RFC 3200. Exceptions to this are some RFCs above RFC 3200. They have been included, given that they obsoleted RFCs within the range 1-3200. Also, the comments presented for each RFC are raw in their nature, i.e., each RFC is simply analysed in terms of possible IPv4 addressing dependencies. Finally, Section 7 presents a global overview of the data described in the previous sections, and suggests possible future steps.
完整、草案和提议的标准，以及实验性RFC。对于每个部分，标准按其RFC编号按顺序进行分析，即从RFC 1到RFC 3200。例外情况是RFC 3200以上的一些RFC。考虑到它们淘汰了1-3200范围内的RFC，因此将其包括在内。此外，为每个RFC提供的注释本质上都是原始的，也就是说，每个RFC只是根据可能的IPv4寻址依赖性进行分析。最后，第7节对前几节中描述的数据进行了总体概述，并提出了未来可能采取的步骤。
Internet Full Standards have attained the highest level of maturity on the standards track process. They are commonly referred to as "Standards", and represent fully technical mature specifications that are widely implemented and used throughout the Internet.
Internet完整标准在标准跟踪过程中已达到最高成熟度。它们通常被称为“标准”，代表了在整个互联网上广泛实施和使用的完全技术成熟的规范。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes the port command using the following format:
第4.1.2节（传输参数命令）使用以下格式描述端口命令：
"A port command would be: PORT h1,h2,h3,h4,p1,p2 where h1 is the high order 8 bits of the internet host address."
“端口命令应该是：端口h1、h2、h3、h4、p1、p2，其中h1是internet主机地址的高阶8位。”
This is a clear reference to an IPv4 address. In sections 4.2.1 and 4.2.2, on reply codes, the code:
这是对IPv4地址的明确引用。在第4.2.1节和第4.2.2节中，关于回复代码，代码：
"227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)"
227进入被动模式（h1、h2、h3、h4、p1、p2）
also needs to be reworked for IPv6 addressing. Also, Section 5.3.2 (FTP COMMAND ARGUMENTS) contains:
还需要对IPv6寻址进行修改。此外，第5.3.2节（FTP命令参数）包含：
"<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255"
"<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255"
This needs to be solved to transition to IPv6.
这需要解决，才能过渡到IPv6。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
3.18. RFC 1870: SMTP Service Extension for Message Size Declaration
3.18. RFC 1870:邮件大小声明的SMTP服务扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Draft Standards is the nomenclature given to specifications that are on the penultimate maturity level of the IETF standards track process. They are considered to be final specifications, which may only experience changes to solve specific problems found. A specification is only considered to be a Draft Standard if there are at least two known independent and interoperable implementations. Hence, Draft Standards are usually quite mature and widely used.
标准草案是指IETF标准跟踪过程中处于倒数第二成熟度的规范的术语。它们被视为最终规范，可能只有在解决发现的特定问题时才会发生变化。只有当至少有两个已知的独立且可互操作的实现时，规范才被视为标准草案。因此，标准草案通常是相当成熟和广泛使用的。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.4. RFC 1305: Network Time Protocol (Version 3) Specification, Implementation
4.4. RFC 1305：网络时间协议（版本3）规范、实现
Section 3.2.1 (Common Variables) provides the following variable definitions:
第3.2.1节（通用变量）提供了以下变量定义：
"Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port (peer.peerport, pkt.peerport): These are the 32-bit Internet address and 16-bit port number of the peer.
对等地址（Peer.peeraddr，pkt.peeraddr），对等端口（Peer.peerport，pkt.peerport）：这些是对等的32位Internet地址和16位端口号。
Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport, pkt.hostport): These are the 32-bit Internet address and 16-bit port number of the host. They are included among the state variables to support multi-homing."
主机地址（peer.hostaddr，pkt.hostaddr）、主机端口（peer.hostport，pkt.hostport）：这些是主机的32位Internet地址和16位端口号。它们包含在状态变量中，以支持多归宿。”
Section 3.4.3 (Receive Procedure) defines the following procedure:
第3.4.3节（接收程序）定义了以下程序：
"The source and destination Internet addresses and ports in the IP and UDP headers are matched to the correct peer. If there is no match a new instantiation of the protocol machine is created and the association mobilized."
“IP和UDP头中的源和目标Internet地址和端口与正确的对等方匹配。如果不匹配，将创建协议计算机的新实例并激活关联。”
Section 3.6 (Access Control Issues) proposes a simple authentication scheme in the following way:
第3.6节（访问控制问题）以以下方式提出了一个简单的身份验证方案：
"If a more comprehensive trust model is required, the design can be based on an access-control list with each entry consisting of a 32-bit Internet address, 32-bit mask and three-bit mode. If the logical AND of the source address (pkt.peeraddr) and the mask in an entry matches the corresponding address in the entry and the mode (pkt.mode) matches the mode in the entry, the access is allowed; otherwise an ICMP error message is returned to the requestor. Through appropriate choice of mask, it is possible to restrict requests by mode to individual addresses, a particular subnet or net addresses, or have no restriction at all. The access-control list would then serve as a filter controlling which peers could create associations."
“如果需要更全面的信任模型，则设计可以基于访问控制列表，每个条目由32位Internet地址、32位掩码和三位模式组成。如果源地址（pkt.peeraddr）和条目中掩码的逻辑and与条目和模式（pkt.mode）中的对应地址相匹配如果与条目中的模式匹配，则允许访问；否则，将向请求者返回ICMP错误消息。通过适当选择掩码，可以按模式将请求限制为单个地址、特定子网或网络地址，或者完全没有限制。访问控制列表将用作筛选器控制了解哪些对等方可以创建关联。”
Appendix B Section 3 (B.3 Commands) defines the following command:
附录B第3节（B.3命令）定义了以下命令：
"Set Trap Address/Port (6): The command association identifier, status and data fields are ignored. The address and port number for subsequent trap messages are taken from the source address and port of the control message itself. The initial trap counter for trap response messages is taken from the sequence field of the command. The response association identifier, status and data fields are not significant. Implementations should include sanity timeouts which prevent trap transmissions if the monitoring program does not renew this information after a lengthy interval."
“设置陷阱地址/端口（6）：忽略命令关联标识符、状态和数据字段。后续陷阱消息的地址和端口号取自控制消息本身的源地址和端口。陷阱响应消息的初始陷阱计数器取自命令的序列字段。响应关联标识符、状态和数据字段不重要。实施应包括健全超时，如果监控程序在长时间间隔后不更新此信息，则可防止陷阱传输。”
The address clearly assumes the IPv4 version. Also, there are numerous places in sample code and in algorithms that use the above mentioned variables. It seems that there is no reason to modify the actual protocol. A small number of textual changes and an update to implementations, so they can understand both IPv4 and IPv6 addresses, will suffice to have a NTP version that works on both network layer protocols.
该地址显然采用IPv4版本。此外，在示例代码和使用上述变量的算法中有许多地方。似乎没有理由修改实际的协议。对实现进行少量的文本更改和更新，以便他们能够理解IPv4和IPv6地址，就足以使NTP版本同时适用于两种网络层协议。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.8. RFC 2045: Multipurpose Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies
4.8. RFC 2045：多用途Internet邮件扩展（MIME），第一部分：Internet邮件正文格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.10. RFC 2047: MIME, Part Three: Message Header Extensions for Non-ASCII Text
4.10. RFC 2047:MIME，第三部分：非ASCII文本的消息头扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.11. RFC 2049: MIME Part Five: Conformance Criteria and Examples
4.11. RFC 2049:MIME第五部分：一致性标准和示例
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section "Blocksize Option Specification" gives the following example:
“块大小选项规范”一节给出了以下示例：
"For example:
“例如：
+-------+--------+---+--------+---+--------+---+--------+---+
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
+-------+--------+---+--------+---+--------+---+--------+---+
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
is a Read Request, for the file named "foobar", in octet (binary) transfer mode, with a block size of 1428 octets (Ethernet MTU, less the TFTP, UDP and IP header lengths)."
是以八位字节（二进制）传输模式对名为“foobar”的文件的读取请求，块大小为1428个八位字节（以太网MTU，减去TFTP、UDP和IP头长度）
Clearly, the given blocksize example would not work with IPv6 header sizes, but it has no practical implications, since larger blocksizes are also available.
显然，给定的blocksize示例不适用于IPv6头大小，但它没有实际意义，因为也可以使用较大的blocksize。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.17. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax
4.17. RFC2396：统一资源标识符（URI）：通用语法
Section 3.2.2. (Server-based Naming Authority) states:
第3.2.2节。（基于服务器的命名机构）状态：
"The host is a domain name of a network host, or its IPv4 address as a set of four decimal digit groups separated by ".". Literal IPv6 addresses are not supported. ... Note: A suitable representation for including a literal IPv6 address as the host part of a URL is desired, but has not yet been determined or implemented in practice."
“主机是网络主机的域名，或其IPv4地址是一组由“.”分隔的四个十进制数字组。不支持文字IPv6地址……注意：需要将文字IPv6地址包含为URL的主机部分的合适表示形式，但在实践中尚未确定或实现。”
Section 3.2.2 (http URL) states:
第3.2.2节（http URL）规定：
"The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs.
“http”方案用于通过http协议定位网络资源。本节定义了http URL方案特定的语法和语义。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (section 5.1.2). The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24])."
如果端口为空或未给定，则假定端口80。语义是，标识的资源位于侦听该主机端口上TCP连接的服务器上，资源的请求URI为abs_path（第5.1.2节）。应尽可能避免在URL中使用IP地址（见RFC 1900[24]）
The text is version neutral, but it is unclear whether individual implementations will support IPv6 addresses. In fact, the use of the ":"separator in IPv6 addresses will cause misinterpretation when parsing URI's. There are other discussions regarding a server recognizing its own IP addresses, spoofing DNS/IP address combinations, as well as issues regarding multiple HTTP servers running on a single IP interface. Again, the text is version neutral, but clearly, such statements represent implementation issues.
文本与版本无关，但不清楚单个实现是否支持IPv6地址。事实上，在IPv6地址中使用“：”分隔符将在解析URI时导致误解。还有关于服务器识别其自身IP地址、欺骗DNS/IP地址组合的其他讨论，以及关于在单个IP接口上运行的多个HTTP服务器的问题。同样，文本是版本无关的，但很明显，这些声明代表了实现问题。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.22. RFC 3461: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications
4.22. RFC 3461:传递状态通知的简单邮件传输协议（SMTP）服务扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.23. RFC 3462: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
4.23. RFC 3462：用于报告邮件系统管理消息的多部分/报告内容类型
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.25. RFC 3464: An Extensible Message Format for Delivery Status Notifications
4.25. RFC 3464：用于传递状态通知的可扩展消息格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Proposed Standards represent initial level documents in the IETF standards track process. They are stable in terms of design, but do not require the existence of implementations. In several cases, these specifications are simply proposed as solid technical ideas, to be analysed by the Internet community, but are never implemented or advanced in the IETF standards process.
提议的标准代表IETF标准跟踪过程中的初始级文件。它们在设计上是稳定的，但不需要存在实现。在一些情况下，这些规范只是作为坚实的技术思想提出，由互联网社区进行分析，但从未在IETF标准过程中实施或推进。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.2. RFC 726: Remote Controlled Transmission and Echoing Telnet option
5.2. RFC 726：远程控制传输和回显Telnet选项
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section "TTYLOC Number" states:
“TTYLOC编号”一节规定：
"The TTYLOC number is a 64-bit number composed of two (2) 32-bit numbers: The 32-bit official ARPA Internet host address (may be any one of the addresses for multi-homed hosts) and a 32-bit number representing the terminal on the specified host. The host address of [0.0.0.0] is defined to be "unknown", the terminal number of FFFFFFFF (hex, r or-1 in decimal) is defined to be "unknown" and the terminal number of FFFFFFFE (hex, or -2 in decimal) is defined to be "detached" for processes that are not attached to a terminal."
TTYLOC号是一个64位数字，由两（2）个32位数字组成：32位官方ARPA Internet主机地址（可以是多主机主机的任何一个地址）和一个32位数字，代表指定主机上的终端。主机地址[0.0.0.0]定义为“未知”，即FFFFFF的终端号（十进制中的十六进制、r或-1）定义为“未知”，对于未连接到终端的进程，FFFFF E的终端号（十进制中的十六进制或-2）定义为“分离”
The clear reference to 32-bit numbers, and to the use of literal addresses in the form [0.0.0.0] is clearly an IPv4-dependency. Thus, the text above needs to be re-written.
对32位数字的明确引用，以及对[0.0.0.0]形式的文字地址的使用，显然是一种IPv4依赖关系。因此，上述文本需要重新编写。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.14. RFC 1043: Telnet Data Entry Terminal option: DODIIS implementation
5.14. RFC 1043:Telnet数据输入终端选项：DODIIS实现
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.21. RFC 1276: Replication and Distributed Operations extensions to provide an Internet Directory using X.500
5.21. RFC 1276：使用X.500提供Internet目录的复制和分布式操作扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.22. RFC 1314: A File Format for the Exchange of Images in the Internet
5.22. RFC 1314：用于在Internet上交换图像的文件格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Since this document defines a gateway for interaction between FTAM and FTP, the only possible IPv4 dependencies are associated with FTP, which has already been investigated above, in section 3.16.
由于本文档定义了FTAM和FTP之间交互的网关，因此唯一可能的IPv4依赖关系与FTP相关，这已在上文第3.16节中进行了研究。
5.26. RFC 1494: Equivalences between 1988 X.400 and RFC-822 Message Bodies
5.26. RFC 1494:1988 X.400和RFC-822消息体之间的等效性
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.27. RFC 1496: Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages
5.27. RFC 1496：当消息中存在MIME内容类型时，将消息从X.400/88降级到X.400/84的规则
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section 3.1. (Common Internet Scheme Syntax) states:
第3.1节。（通用互联网方案语法）说明：
"host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [4]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses."
“主机网络主机的完全限定域名，或其IP地址为一组由“.”分隔的四个十进制数字组。完全限定域名采用RFC 1034[13]第3.5节和RFC 1123[4]第2.1节所述的形式：由“.”分隔的域标签序列。，每个域标签以字母数字字符开头和结尾，可能还包含“-”字符。然而，最右边的域名标签永远不会以数字开头，这在语法上区分了所有域名和IP地址。”
Clearly, this is only valid when using IPv4 addresses. Later in Section 5. (BNF for specific URL schemes), there is the following text:
显然，这仅在使用IPv4地址时有效。稍后在第5节。（针对特定URL方案的BNF），有以下文本：
"; URL schemeparts for ip based protocols:
“基于ip的协议的URL方案部件：
ip-schemepart = "//" login [ "/" urlpath ]
ip-schemepart = "//" login [ "/" urlpath ]
login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname | hostnumber"
login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname | hostnumber"
Again, this also has implications in terms of IP-version neutrality.
同样，这对IP版本中立性也有影响。
5.32. RFC 1740: MIME Encapsulation of Macintosh Files - MacMIME
5.32. RFC 1740:Macintosh文件的MIME封装-MacMIME
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section 6.5. (Query referral) makes the following statement:
第6.5节。（查询转介）作出以下声明：
"When referrals are included in the body of a response to a query, each referral is listed in a separate SERVER-TO-ASK block as shown below.
“当查询响应的正文中包含了转介时，每个转介都列在单独的服务器到请求块中，如下所示。
# SERVER-TO-ASK
Version-number: // version number of index software, used to insure
// compatibility
Body-of-Query: // the original query goes here
Server-Handle: // WHOIS++ handle of the referred server
Host-Name: // DNS name or IP address of the referred server
Port-Number: // Port number to which to connect, if different from the
// WHOIS++ port number"
# SERVER-TO-ASK
Version-number: // version number of index software, used to insure
// compatibility
Body-of-Query: // the original query goes here
Server-Handle: // WHOIS++ handle of the referred server
Host-Name: // DNS name or IP address of the referred server
Port-Number: // Port number to which to connect, if different from the
// WHOIS++ port number"
The syntax used does not present specific IPv4 dependencies, but implementations should be modified to check, in incoming packets, which IP version was used by the original request, so they can determine whether or not to return an IPv6 address.
所使用的语法并不表示特定的IPv4依赖关系，但应修改实现以在传入的数据包中检查原始请求使用的IP版本，以便它们可以确定是否返回IPv6地址。
Section 4 (Caching) states the following:
第4节（缓存）说明了以下内容：
"A client can cache all information it gets from a server for some time. For example records, IP-addresses of Whois++ servers, the Directory of Services server etc.
“客户端可以将从服务器获取的所有信息缓存一段时间。例如记录、Whois++服务器的IP地址、服务服务器目录等。
A client can itself choose for how long it should cache the information.
客户机可以自行选择信息的缓存时间。
The IP-address of the Directory of Services server might not change for a day or two, and neither might any other information."
服务目录服务器的IP地址在一两天内可能不会更改，任何其他信息也不会更改。”
Also, subsection 4.1. (Caching a Whois++ servers hostname) contains:
同样，第4.1小节。（缓存Whois++服务器主机名）包含：
"An example of cached information that might change is the cached hostname, IP-address and portnumber which a client gets back in a servers-to-ask response. That information is cached in the server since the last poll, which might occurred several weeks ago. Therefore, when such a connection fails, the client should fall back to use the serverhandle instead, which means that it contacts the Directory of Services server and queries for a server with that serverhandle. By doing this, the client should always get the last known hostname.
“缓存信息可能会更改的一个示例是缓存的主机名、IP地址和端口号，客户端会在服务器中返回这些信息以请求响应。自上一次轮询（可能发生在几周前）以来，这些信息会缓存在服务器中。因此，当这种连接失败时，客户端应该返回使用serverhandle，这意味着它联系服务服务器目录并查询具有该serverhandle的服务器。通过这样做，客户端应始终获得最后一个已知的主机名。
An algorithm for this might be:
这方面的算法可能是：
response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
connect to Directory of Services server
query for host with serverhandle response.serverhandle
response := response from Directory of Services server
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
exit with error message
}
}
Query this new server"
response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
connect to Directory of Services server
query for host with serverhandle response.serverhandle
response := response from Directory of Services server
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
exit with error message
}
}
Query this new server"
The paragraph does not contain IPv4 specific syntax. Hence, IPv6 compliance will be implementation dependent.
该段落不包含IPv4特定的语法。因此，IPv6遵从性将取决于实现。
5.38. RFC 1985: SMTP Service Extension for Remote Message Queue Starting
5.38. RFC 1985:启动远程邮件队列的SMTP服务扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.39. RFC 2017: Definition of the URL MIME External-Body Access-Type
5.39. RFC 2017：URL MIME外部主体访问类型的定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.40. RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes
5.40. RFC 2034:用于返回增强错误代码的SMTP服务扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.42. RFC 2077: The Model Primary Content Type for Multipurpose Internet Mail Extensions
5.42. RFC 2077：多用途Internet邮件扩展的主要内容类型模型
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.43. RFC 2079: Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)
5.43. RFC 2079:X.500属性类型和用于保存统一资源标识符（URI）的对象类的定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section 3 (Description of the VEMMI scheme) states:
第3节（VEMMI方案说明）规定：
"The VEMMI URL scheme is used to designate multimedia interactive services conforming to the VEMMI standard (ITU/T T.107 and ETS 300 709).
“VEMMI URL方案用于指定符合VEMMI标准（ITU/T.107和ETS 300 709）的多媒体交互服务。
A VEMMI URL takes the form:
vemmi://<host>:<port>/<vemmiservice>;
<attribute>=<value>
A VEMMI URL takes the form:
vemmi://<host>:<port>/<vemmiservice>;
<attribute>=<value>
as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the port defaults to 575 (client software may choose to ignore the optional port number in order to increase security). The <vemmiservice> part is optional and may be omitted."
如第3.1节所述。根据RFC1738的规定。如果省略：<port>，则端口默认为575（客户端软件可以选择忽略可选端口号以提高安全性）。<vemmiservice>部分是可选的，可以省略。”
IPv4 dependencies may relate to the possibility of the <host> portion containing an IPv4 address, as defined in RFC 1738 (see section 5.31. above). Once the problem is solved in the context of RFC 1738, this issue will be automatically solved.
IPv4依赖关系可能与包含IPv4地址的<host>部分的可能性有关，如RFC 1738中所定义（见上文第5.31节）。一旦问题在RFC 1738中得到解决，该问题将自动得到解决。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.49. RFC 2142: Mailbox Names for Common Services, Roles and Functions
5.49. RFC 2142：公用服务、角色和功能的邮箱名称
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.50. RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME
5.50. RFC 2156:混音器（Mime Internet X.400增强型中继）：X.400和RFC 822/Mime之间的映射
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.51. RFC 2157: Mapping between X.400 and RFC-822/MIME Message Bodies
5.51. RFC 2157:X.400和RFC-822/MIME消息体之间的映射
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.55. RFC 2163: Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping
5.55. RFC 2163：使用Internet DNS分发符合混合器的全局地址映射
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.56. RFC 2164: Use of an X.500/LDAP directory to support MIXER address mapping
5.56. RFC 2164：使用X.500/LDAP目录支持混音器地址映射
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section 7. (Service Type Request Message Format) and Section 9. (Service Registration Message Format) have an 80-bit field from addr-spec (see below) which cannot support IPv6 addresses. Also, Section 20.1. (Previous Responders' Address Specification) states:
第7节。（服务类型请求消息格式）和第9节。（服务注册消息格式）具有来自addr spec（见下文）的80位字段，该字段不支持IPv6地址。此外，第20.1节。（先前响应者的地址规范）说明：
"The previous responders' Address Specification is specified as
“先前响应者的地址规范指定为
<Previous Responders' Address Specification> ::=
<addr-spec> |
<addr-spec>, <Previous Responders' Address Specification>
<Previous Responders' Address Specification> ::=
<addr-spec> |
<addr-spec>, <Previous Responders' Address Specification>
i.e., a list separated by commas with no intervening white space. The Address Specification is the address of the Directory Agent or Service Agent which supplied the previous response. The format for Address Specifications in Service Location is defined in section 20.4. The comma delimiter is required between each <addr-spec>. The use of dotted decimal IP address notation should only be used in environments which have no Domain Name Service."
i、 例如，用逗号分隔的列表，中间没有空格。地址规范是提供先前响应的目录代理或服务代理的地址。第20.4节定义了服务位置地址规范的格式。每个<addr spec>之间需要逗号分隔符。只有在没有域名服务的环境中才能使用点十进制IP地址表示法。”
Later, in Section 20.4. (Address Specification in Service Location) there is also the following reference to addr-spec:
稍后，在第20.4节。（服务位置中的地址规范）addr规范也有以下参考：
"The address specification used in Service Location is:
“服务位置中使用的地址规范为：
<addr-spec> ::= [<user>:<password>@]<host>[:<port>]
<addr-spec> ::= [<user>:<password>@]<host>[:<port>]
<host> ::= Fully qualified domain name |
dotted decimal IP address notation
<host> ::= Fully qualified domain name |
dotted decimal IP address notation
When no Domain Name Server is available, SAs and DAs must use dotted decimal conventions for IP addresses. Otherwise, it is preferable to use a fully qualified domain name wherever possible as renumbering of host addresses will make IP addresses invalid over time."
当没有可用的域名服务器时，SAs和DAs必须对IP地址使用点十进制约定。否则，最好尽可能使用完全限定的域名，因为主机地址的重新编号会使IP地址随着时间的推移而无效。”
The whole Section 21. (Protocol Requirements) defines the requirements for each of the elements of this protocol. Several IPv4 statements are made, but the syntax used is sufficiently neutral to apply to the use of IPv6.
整个第21节。（协议要求）定义了本协议各要素的要求。有几个IPv4语句，但所使用的语法足够中立，可以应用于IPv6的使用。
Section 22. (Configurable Parameters and Default Values) states:
第22节。（可配置参数和默认值）状态：
"There are several configuration parameters for Service Location. Default values are chosen to allow protocol operation without the need for selection of these configuration parameters, but other values may be selected by the site administrator. The configurable parameters will allow an implementation of Service Location to be more useful in a variety of scenarios.
“服务位置有几个配置参数。选择默认值以允许协议操作，而无需选择这些配置参数，但站点管理员可以选择其他值。可配置参数将允许服务位置的实现在var中更有用。”各种各样的场景。
Multicast vs. Broadcast All Service Location entities must use multicast by default. The ability to use broadcast messages must be configurable for UAs and SAs. Broadcast messages are to be used in environments where not all Service Location entities have hardware or software which supports multicast.
多播与广播默认情况下，所有服务位置实体都必须使用多播。必须为UAs和SAs配置使用广播消息的能力。广播消息将用于并非所有服务位置实体都具有支持多播的硬件或软件的环境中。
Multicast Radius Multicast requests should be sent to all subnets in a site. The default multicast radius for a site is 32. This value must be configurable. The value for the site's multicast TTL may be obtained from DHCP using an option which is currently unassigned."
多播Radius多播请求应发送到站点中的所有子网。站点的默认多播半径为32。此值必须是可配置的。可使用当前未分配的选项从DHCP获取站点的多播TTL值。”
Once again, nothing here precludes IPv6, Section 23.
再一次，这里的任何内容都不排除IPv6，第23节。
(Non-configurable Parameters) states:
（不可配置参数）状态：
"IP Port number for unicast requests to Directory Agents:
“对目录代理的单播请求的IP端口号：
UDP and TCP Port Number: 427
UDP和TCP端口号：427
Multicast Addresses
多播地址
Service Location General Multicast Address: 224.0.1.22 Directory Agent Discovery Multicast Address: 224.0.1.35
服务位置通用多播地址：224.0.1.22目录代理发现多播地址：224.0.1.35
A range of 1024 contiguous multicast addresses for use as Service Specific Discovery Multicast Addresses will be assigned by IANA."
IANA将分配1024个连续多播地址作为特定于服务的发现多播地址。”
Clearly, the statements above require specifications related to the use of IPv6 multicast addresses with equivalent functionality.
显然，上述声明需要与具有同等功能的IPv6多播地址的使用相关的规范。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.59. RFC 2183: Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
5.59. RFC 2183：在Internet消息中传递表示信息：内容处置头字段
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
The specification has IPv4 dependencies, as RFC 1738, which is integral to the document, is not IPv6 aware.
该规范具有IPv4依赖关系，因为RFC 1738（文档的一部分）不支持IPv6。
Section 6. (Formal Syntax) presents the following statement:
第6节。（正式语法）表示以下语句：
"referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; See
[RFC-1738] for <url> definition"
"referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; See
[RFC-1738] for <url> definition"
The above presents dependencies on RFC 1738 URL definitions, which have already been mentioned in this document, section 5.31.
上述内容提供了对RFC 1738 URL定义的依赖关系，本文件第5.31节已经提到了这些定义。
5.62. RFC 2218: A Common Schema for the Internet White Pages Service
5.62. RFC2218：Internet白页服务的通用模式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the following example:
第4.1节。（登录和验证推荐）提供了以下示例：
"Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try SERVER2."
"Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try SERVER2."
Even though the syntax "user@SERVER2" is presented often, there are no specifications related to the format of "SERVER2". Hence, it is up to individual implementations to determine acceptable values for the hostname. This may or not include explicit IPv6 addresses.
即使是“语法”user@SERVER2“SERVER2”的格式经常出现，但没有与“SERVER2”格式相关的规范。因此，主机名的可接受值取决于各个实现。这可能包括也可能不包括明确的IPv6地址。
5.64. RFC 2227: Simple Hit-Metering and Usage-Limiting for HTTP
5.64. RFC 2227：HTTP的简单命中计数和使用限制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.65. RFC 2231: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
5.65. RFC 2231:MIME参数值和编码字扩展：字符集、语言和连续体
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.68. RFC 2247: Using Domains in LDAP/X.500 Distinguished Names
5.68. RFC 2247:在LDAP/X.500可分辨名称中使用域
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.70. RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
5.70. RFC2252：轻量级目录访问协议（v3）：属性语法定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.71. RFC 2253: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
5.71. RFC2253：轻量级目录访问协议（v3）：可分辨名称的UTF-8字符串表示
Section 7.1. (Disclosure) states:
第7.1节。（披露）声明：
"Distinguished Names typically consist of descriptive information about the entries they name, which can be people, organizations, devices or other real-world objects. This frequently includes some of the following kinds of information:
“可分辨名称通常包括有关其命名的条目的描述性信息，这些条目可以是人、组织、设备或其他现实世界对象。这通常包括以下几种信息：
- the common name of the object (i.e., a person's full name) - an email or TCP/IP address - its physical location (country, locality, city, street address) - organizational attributes (such as department name or affiliation)"
- 对象的通用名称（即某人的全名）-电子邮件或TCP/IP地址-其物理位置（国家、地区、城市、街道地址）-组织属性（如部门名称或隶属关系）”
This section requires the caveat "Without putting any limitations on the version of the IP address.", to avoid ambiguity in terms of IP version.
本节要求注意“不限制IP地址的版本”，以避免IP版本方面的歧义。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
The specification has IPv4 dependencies, as RFC 1738, which is integral to the document, is not IPv6 aware.
该规范具有IPv4依赖关系，因为RFC 1738（文档的一部分）不支持IPv6。
5.74. RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3
5.74. RFC2256：用于LDAPv3的X.500（96）用户模式摘要
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.75. RFC 2293: Representing Tables and Subtrees in the X.500 Directory
5.75. RFC 2293:表示X.500目录中的表和子树
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.76. RFC 2294: Representing the O/R Address hierarchy in the X.500 Directory Information Tree
5.76. RFC 2294:表示X.500目录信息树中的O/R地址层次结构
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.77. RFC 2298: An Extensible Message Format for Message Disposition Notifications
5.77. RFC 2298：用于消息处置通知的可扩展消息格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Appendix B, part 2.0.1 (Mandatory Common Part) states:
附录B第2.0.1部分（强制性通用部分）规定：
"Cache Key This is a database lookup key that uniquely identifies a piece of data which the originator of a CSA Record wishes to synchronize with its peers for a given "Protocol ID/Server Group ID" pair. This key will generally be a small opaque byte string which SCSP will associate with a given piece of data in a cache. Thus, for example, an originator might assign a particular 4 byte string to the binding of an IP address with that of an ATM address. Generally speaking, the originating server of a CSA record is responsible for generating a Cache Key for every element of data that the given server originates and which the server wishes to synchronize with its peers in the SG."
“缓存密钥这是一个数据库查找密钥，它唯一标识CSA记录的发起人希望与其对等方同步的给定“协议ID/服务器组ID”数据段“一对。该键通常是一个不透明的小字节字符串，SCSP将其与缓存中的给定数据段相关联。因此，例如，发起者可能会将特定的4字节字符串分配给IP地址与ATM地址的绑定。一般来说，CSA记录的发起服务器负责为给定服务器发起并希望与SG中的对等方同步的每个数据元素生成缓存密钥。”
The statement above is simply meant as an example. Hence, any IPv4 possible dependency of this protocol is an implementation issue.
上面的陈述只是作为一个例子。因此，此协议的任何IPv4可能依赖性都是一个实现问题。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.84. RFC 2369: The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
5.84. RFC 2369：使用URL作为核心邮件列表命令的元语法，并通过消息头字段传输
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
In section 7. (TIP Transaction Manager Identification and Connection Establishment):
第7节。（TIP交易管理器标识和连接建立）：
"The <hostport> component comprises:
“组件包括：
<host>[:<port>]
<host>[:<port>]
where <host> is either a <dns name> or an <ip address>; and <port> is a decimal number specifying the port at which the transaction manager (or proxy) is listening for requests to establish TIP connections. If the port number is omitted, the standard TIP port number (3372) is used.
其中<host>是<dns name>或<ip地址>；<port>是一个十进制数，指定事务管理器（或代理）侦听建立TIP连接请求的端口。如果省略端口号，则使用标准TIP端口号（3372）。
A <dns name> is a standard name, acceptable to the domain name service. It must be sufficiently qualified to be useful to the receiver of the command.
<dns名称>是域名服务可接受的标准名称。它必须足够合格，以便对命令接收者有用。
An <ip address> is an IP address, in the usual form: four decimal numbers separated by period characters."
<ip地址>是一个ip地址，通常形式为：四个十进制数字，由句点字符分隔。”
This section has to be re-written to become IP-version neutral. Besides adding a reference to the use of IPv6 addresses, the "host" field should only be defined as a "dns name". However, if the use of literal IP addresses is to be included, the format specified in RFC 2372 has to be followed.
必须重新编写本节，使其成为IP版本中立。除了添加对IPv6地址使用的引用外，“主机”字段应仅定义为“dns名称”。但是，如果要包括文字IP地址的使用，则必须遵循RFC 2372中指定的格式。
Later in section 8. (TIP Uniform Resource Locators):
稍后在第8节。（提示统一资源定位器）：
"A TIP URL takes the form:
“提示URL的形式如下：
tip://<transaction manager address>?<transaction string>
tip://<transaction manager address>?<transaction string>
where <transaction manager address> identifies the TIP transaction manager (as defined in Section 7 above); and <transaction string> specifies a transaction identifier, which may take one of two forms (standard or non-standard):
其中，<transaction manager address>标识TIP交易经理（定义见上文第7节）；和<transaction string>指定一个事务标识符，它可以采用两种形式之一（标准或非标准）：
i. "urn:" <NID> ":" <NSS>
i. "urn:" <NID> ":" <NSS>
A standard transaction identifier, conforming to the proposed Internet Standard for Uniform Resource Names (URNs), as specified by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is the Namespace Specific String. The Namespace ID determines the syntactic interpretation of the Namespace Specific String. The Namespace Specific String is a sequence of characters representing a transaction identifier (as defined by <NID>). The rules for the contents of these fields are specified by [6] (valid characters, encoding, etc.).
标准事务标识符，符合RFC2141规定的统一资源名称（URN）的拟议互联网标准；其中<NID>是名称空间标识符，<NSS>是特定于名称空间的字符串。命名空间ID确定命名空间特定字符串的语法解释。命名空间特定的字符串是表示事务标识符的字符序列（由<NID>定义）。这些字段内容的规则由[6]指定（有效字符、编码等）。
This format of <transaction string> may be used to express global transaction identifiers in terms of standard representations. Examples for <NID> might be <iso> or <xopen>. e.g.,
<transaction string>的这种格式可用于以标准表示形式表示全局事务标识符。<NID>的示例可能是<iso>或<xopen>。例如。，
tip://123.123.123.123/?urn:xopen:xid
tip://123.123.123.123/?urn:xopen:xid
Note that Namespace Ids require registration. See [7] for details on how to do this."
请注意，命名空间ID需要注册。有关如何执行此操作的详细信息，请参见[7]
There are other references in section 8, regarding the use of literal IP addresses. Therefore, this section also needs to be re-written, and special care should be taken to avoid the use of IP (either IPv4 or IPv6) literal addresses. However, if such use is exemplified, the format specified in RFC 2732 has to be respected.
第8节中还有其他关于文字IP地址使用的参考资料。因此，本节也需要重新编写，并且应特别注意避免使用IP（IPv4或IPv6）文本地址。但是，如果举例说明这种使用，则必须遵守RFC 2732中规定的格式。
Section 3. (POP Scheme) states:
第3节。（POP计划）规定：
"A POP URL is of the general form:
“POP URL的一般形式为：
pop://<user>;auth=<auth>@<host>:<port>
pop://<user>;auth=<auth>@<host>:<port>
Where <user>, <host>, and <port> are as defined in RFC 1738, and
some or all of the elements, except "pop://" and <host>, may be
omitted."
Where <user>, <host>, and <port> are as defined in RFC 1738, and
some or all of the elements, except "pop://" and <host>, may be
omitted."
RFC 1738 (please refer to section 5.31) has a potential IPv4 limitation. Hence, RFC 2384 will only be IPv6 compliant when RFC 1738 becomes properly updated.
RFC 1738（请参阅第5.31节）具有潜在的IPv4限制。因此，只有当RFC 1738得到正确更新时，RFC 2384才符合IPv6。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.89. RFC 2389: Feature negotiation mechanism for the File Transfer Protocol
5.89. RFC 2389：文件传输协议的功能协商机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.90. RFC 2392: Content-ID and Message-ID Uniform Resource Locators (CIDMID-URL)
5.90. RFC 2392：内容ID和消息ID统一资源定位器（CIDMID-URL）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.93. RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration
5.93. RFC 2422：收费质量语音-32 kbit/s ADPCM MIME子类型注册
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This RFC documents an IPv6 extension and hence, it is not considered in the context of the current discussion.
此RFC记录了IPv6扩展，因此，在当前讨论的上下文中不考虑此扩展。
5.99. RFC 2445: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
5.99. RFC 2445：互联网日历和调度核心对象规范（iCalendar）
Section 4.8.4.7 (Unique Identifier) states:
第4.8.4.7节（唯一标识符）规定：
"Property Name: UID
“属性名称：UID
Purpose: This property defines the persistent, globally unique identifier for the calendar component.
用途：此属性定义日历组件的持久、全局唯一标识符。
Value Type: TEXT
值类型：文本
Property Parameters: Non-standard property parameters can be specified on this property.
属性参数：可以在此属性上指定非标准属性参数。
Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
一致性：必须在“VEVENT”、“VTODO”、“VJOURNAL”或“VFREEBUSY”日历组件中指定该属性。
Description: The UID itself MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [RFC 822] addr-spec. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of the "@", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts should be using the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain."
描述：UID本身必须是全局唯一标识符。标识符的生成器必须保证标识符是唯一的。有几种算法可以用来实现这一点。建议标识符采用与[RFC 822]addr-spec相同的语法。确保唯一性的一个好方法是将创建标识符的主机的域名或域文字IP地址放在“@”的右侧和左侧，将当前日历日期和时间（即，格式化为日期时间值）与系统上可用的其他当前唯一（可能是顺序）标识符（例如，进程id号）组合在一起。在左侧使用日期/时间值，在右侧使用域名或域文字，可以保证唯一性，因为没有两台主机应同时使用相同的域名或IP地址。尽管其他算法也可以工作，但建议右侧包含一些域标识符（主机本身或其他），以便消息标识符的生成器可以保证左侧在该域范围内的唯一性。”
Although the above does not explicitly state the use of IPv4 addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC 2822). To become IPv6 compliant it should follow the guidelines for RFC 2822 (see section 5.129).
尽管上面没有明确说明IPv4地址的使用，但它明确说明了RFC 822的使用（已被RFC 2822淘汰）。要符合IPv6，应遵循RFC 2822的指南（参见第5.129节）。
5.100. RFC 2446: iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
5.100. RFC 2446:iCalendar传输独立互操作性协议（iTIP）调度事件、忙碌时间、待办事项和日志条目
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.101. RFC 2447: iCalendar Message-Based Interoperability Protocol (iMIP)
5.101. RFC 2447:iCalendar基于消息的互操作性协议（iMIP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.102. RFC 2449: POP3 Extension Mechanism
5.102. RFC2449:POP3扩展机制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.103. RFC 2476: Message Submission
5.103. RFC 2476：邮件提交
This RFC contains several discussions on the usage of IP Address authorization schemes, but it does not limit those addresses to IPv4.
本RFC包含关于IP地址授权方案使用的若干讨论，但并不将这些地址限制为IPv4。
5.104. RFC 2480: Gateways and MIME Security Multiparts
5.104. RFC 2480：网关和MIME安全多部分
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.105. RFC 2518: HTTP Extensions for Distributed Authoring
5.105. RFC 2518：用于分布式创作的HTTP扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.106. RFC 2530: Indicating Supported Media Features Using Extensions to DSN and MDN
5.106. RFC 2530:使用DSN和MDN的扩展指示支持的媒体功能
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.107. RFC 2532: Extended Facsimile Using Internet Mail
5.107. RFC 2532：使用互联网邮件的扩展传真
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.108. RFC 2533: A Syntax for Describing Media Feature Sets
5.108. RFC2533：描述媒体功能集的语法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.109. RFC 2534: Media Features for Display, Print, and Fax
5.109. RFC 2534：用于显示、打印和传真的媒体功能
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.110. RFC 2554: SMTP Service Extension for Authentication
5.110. RFC 2554:用于身份验证的SMTP服务扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.111. RFC 2557: MIME Encapsulation of Aggregate Documents, such as HTML
5.111. RFC2557：聚合文档（如HTML）的MIME封装
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.112. RFC 2589: Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
5.112. RFC2589：轻量级目录访问协议（v3）：动态目录服务的扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.113. RFC 2595: Using TLS with IMAP, POP3 and ACAP
5.113. RFC 2595：将TLS与IMAP、POP3和ACAP一起使用
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.114. RFC 2596: Use of Language Codes in LDAP
5.114. RFC2596：LDAP中语言代码的使用
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.115. RFC 2608: Service Location Protocol, Version 2
5.115. RFC 2608：服务位置协议，版本2
Section 8.1. (Service Request) contains the following:
第8.1节。（服务请求）包含以下内容：
"
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
<PRList> is the Previous Responder List. This <string-list> contains dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results (see Section 6.3). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they are not already configured with DA addresses by some other means."
<PRList>是以前的响应者列表。该<string list>包含点十进制表示法IP（v4）地址，并通过迭代多播获得所有可能的结果（见第6.3节）。UAs应该实现这个发现算法。如果SAs尚未通过其他方式配置DA地址，则必须使用此功能来发现其作用域中的所有可用DA。”
And later:
后来：
"A SA silently drops all requests which include the SA's address in the <PRList>. An SA which has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the <PRList> is processed normally and an error is not returned."
“SA会以静默方式删除<PRList>中包含SA地址的所有请求。具有多个网络接口的SA必须检查<PRList>中的任何条目是否等于其任何接口。PRList中不符合IPv4点十进制地址的条目将被忽略：<PRList>的其余部分将正常处理，并且不会返回错误。“
To become IPv6 compliant, this protocol requires a new version.
要与IPv6兼容，此协议需要新版本。
5.116. RFC 2609: Service Templates and Service: Schemes
5.116. RFC 2609：服务模板和服务：方案
Section 2.1. (Service URL Syntax) defines:
第2.1节。（服务URL语法）定义：
"The ABNF for a service: URL is:
“服务URL的ABNF为：
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)"
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)"
This document presents many other references to hostnumber, which requires an update to support IPv6.
本文档提供了对hostnumber的许多其他参考，hostnumber需要更新以支持IPv6。
5.117. RFC 2640: Internationalization of the File Transfer Protocol
5.117. RFC 2640：文件传输协议的国际化
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.118. RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses
5.118. RFC 2645:具有动态IP地址的按需邮件中继（ODMR）SMTP
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.119. RFC 2646: The Text/Plain Format Parameter
5.119. RFC 2646:文本/纯格式参数
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.120. RFC 2651: The Architecture of the Common Indexing Protocol (CIP)
5.120. RFC 2651：公共索引协议（CIP）的体系结构
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.121. RFC 2652: MIME Object Definitions for the Common Indexing Protocol
5.121. RFC 2652：通用索引协议的MIME对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.122. RFC 2653: CIP Transport Protocols
5.122. RFC 2653:CIP传输协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.123. RFC 2732: Format for Literal IPv6 Addresses in URL's
5.123. RFC 2732:URL中文本IPv6地址的格式
This document defines an IPv6 specific protocol and hence, it is not discussed in this document.
本文档定义了一个特定于IPv6的协议，因此，本文档不讨论该协议。
5.124. RFC 2738: Corrections to "A Syntax for Describing Media Feature Sets"
5.124. RFC 2738：对“描述媒体功能集的语法”的更正
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.125. RFC 2739: Calendar Attributes for vCard and LDAP
5.125. RFC 2739:vCard和LDAP的日历属性
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.126. RFC 2806: URLs for Telephone Calls
5.126. RFC 2806：电话呼叫的URL
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.127. RFC 2821: Simple Mail Transfer Protocol
5.127. RFC 2821：简单邮件传输协议
The specification discusses A records at length, and the MX record handling with the different combinations of A and AAAA records and IPv4/IPv6-only nodes might cause several kinds of failure modes.
该规范详细讨论了A记录，使用A和AAAA记录的不同组合以及仅IPv4/IPv6节点处理MX记录可能会导致几种故障模式。
5.128. RFC 2822: Internet Message Format
5.128. RFC 2822：Internet消息格式
Section 3.4.1 (Addr-spec specification) contains:
第3.4.1节（Addr规范）包含：
"The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [STD3, STD13, STD14]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host. In both cases, how addressing is used and how messages are transported to a particular host is covered in the mail transport document [RFC2821]. These mechanisms are outside of the scope of this document.
域部分标识邮件传递到的点。在点原子形式中，这被解释为[STD3、STD13、STD14]中所述的Internet域名（主机名或邮件交换名称）。在域文本形式中，域被解释为特定主机的文本Internet地址。在这两种情况下，邮件传输文档[RFC2821]中介绍了如何使用寻址以及如何将邮件传输到特定主机。这些机制不在本文档的范围内。
The local-part portion is a domain dependent string. In addresses, it is simply interpreted on the particular host as a name of a particular mailbox."
本地部分是依赖于域的字符串。在地址中，它只是在特定主机上解释为特定邮箱的名称。”
Literal IP addresses should be avoided. However, in case they are used, there should be a reference to the format described in RFC 2732.
应避免使用文字IP地址。但是，如果使用它们，则应参考RFC 2732中描述的格式。
5.129. RFC 2846: GSTN Address Element Extensions in E-mail Services
5.129. RFC 2846:电子邮件服务中的GSTN地址元素扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.130. RFC 2849: The LDAP Data Interchange Format (LDIF) - Technical Specification
5.130. RFC 2849:LDAP数据交换格式（LDIF）.技术规范
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.131. RFC 2852: Deliver By SMTP Service Extension
5.131. RFC 2852:通过SMTP服务扩展传递
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.132. RFC 2879: Content Feature Schema for Internet Fax (V2)
5.132. RFC 2879:Internet传真的内容功能架构（V2）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.133. RFC 2891: LDAP Control Extension for Server Side Sorting of Search Results
5.133. RFC 2891:用于搜索结果服务器端排序的LDAP控件扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.134. RFC 2910: Internet Printing Protocol/1.1: Encoding and Transport
5.134. RFC 2910：互联网打印协议/1.1：编码和传输
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.135. RFC 2911: Internet Printing Protocol/1.1: Model and Semantics
5.135. RFC 2911：Internet打印协议/1.1：模型和语义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.136. RFC 2912: Indicating Media Features for MIME Content
5.136. RFC 2912:指示MIME内容的媒体功能
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.137. RFC 2913: MIME Content Types in Media Feature Expressions
5.137. RFC 2913:媒体功能表达式中的MIME内容类型
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.138. RFC 2919: List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
5.138. RFC 2919:List Id：用于标识邮件列表的结构化字段和命名空间
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.139. RFC 2938: Identifying Composite Media Features
5.139. RFC 2938：识别复合介质特征
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.140. RFC 2965: HTTP State Management Mechanism
5.140. RFC 2965:HTTP状态管理机制
This document includes several references to host IP addresses, but there is no explicit mention to a particular protocol version. A caveat similar to "Without putting any limitations on the version of the IP address." should be added, so that there will remain no doubts about possible IPv4 dependencies.
本文档包括对主机IP地址的几处引用，但没有明确提及特定的协议版本。应该添加类似于“不对IP地址的版本设置任何限制”的警告，这样就不会对可能的IPv4依赖性产生怀疑。
5.141. RFC 2971: IMAP4 ID extension
5.141. RFC 2971:IMAP4 ID扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.142. RFC 2987: Registration of Charset and Languages Media Features Tags
5.142. RFC 2987：字符集和语言媒体功能标签的注册
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.143. RFC 3009: Registration of parityfec MIME types
5.143. RFC 3009：注册parityfec MIME类型
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.144. RFC 3017: XML DTD for Roaming Access Phone Book
5.144. RFC 3017：用于漫游访问电话簿的XML DTD
Section 6.2.1. (DNS Server Address) states:
第6.2.1节。（DNS服务器地址）状态：
"The dnsServerAddress element represents the IP address of the Domain Name Service (DNS) server which should be used when connected to this POP.
“dnsServerAddress元素表示连接到此POP时应使用的域名服务（DNS）服务器的IP地址。
The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1).
地址以带点十进制符号的字符串形式表示（例如192.168.101.1）。
Syntax:
<!-- Domain Name Server IP address -->
<!ELEMENT dnsServerAddress (#PCDATA)>
<!ATTLIST dnsServerAddress
value NOTATION (IPADR) #IMPLIED>"
Syntax:
<!-- Domain Name Server IP address -->
<!ELEMENT dnsServerAddress (#PCDATA)>
<!ATTLIST dnsServerAddress
value NOTATION (IPADR) #IMPLIED>"
Additionally, it is stated in Section 6.2.9. (Default Gateway Address):
此外，第6.2.9节对其进行了说明。（默认网关地址）：
"The defaulttGatewayAddress element represents the address of the default gateway which should be used when connected to this POP. The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1).
“defaulttGatewayAddress元素表示连接到此POP时应使用的默认网关的地址。该地址以带点十进制符号的字符串形式表示（例如192.168.101.1）。
Syntax:
<!-- Default Gateway IP address (in dotted decimal notation) -->
<!ELEMENT defaultGatewayAddress (#PCDATA)>
<!ATTLIST defaultGatewayAddress
value NOTATION (IPADR) #IMPLIED>"
Syntax:
<!-- Default Gateway IP address (in dotted decimal notation) -->
<!ELEMENT defaultGatewayAddress (#PCDATA)>
<!ATTLIST defaultGatewayAddress
value NOTATION (IPADR) #IMPLIED>"
It should be straightforward to implement elements that are IPv6 aware.
实现支持IPv6的元素应该很简单。
5.145. RFC 3023: XML Media Types
5.145. RFC 3023:XML媒体类型
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.146. RFC 3028: Sieve: A Mail Filtering Language
5.146. RFC3028:Sieve：邮件过滤语言
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.147. RFC 3030: SMTP Service Extensions for Transmission of Large and Binary MIME Messages
5.147. RFC 3030:用于传输大型和二进制MIME消息的SMTP服务扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.148. RFC 3049: TN3270E Service Location and Session Balancing
5.148. RFC 3049:TN3270E服务位置和会话平衡
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.149. RFC 3059: Attribute List Extension for the Service Location Protocol
5.149. RFC 3059:服务位置协议的属性列表扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.150. RFC 3080: The Blocks Extensible Exchange Protocol Core (BEEP)
5.150. RFC 3080：块可扩展交换协议核心（BEEP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.151. RFC 3081: Mapping the BEEP Core onto TCP
5.151. RFC 3081:将BEEP核心映射到TCP
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.152. RFC 3111: Service Location Protocol Modifications for IPv6
5.152. RFC 3111：IPv6的服务位置协议修改
This is an IPv6 related document and is not discussed in this document.
这是一份与IPv6相关的文档，本文档中没有讨论。
5.153. RFC 3302: Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
5.153. RFC 3302：标记图像文件格式（TIFF）-图像/TIFF MIME子类型注册
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.154. RFC 3404: Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application
5.154. RFC3404：动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）解析应用程序
This specification has no explicit dependency on IPv4. However, when referring to the URI format specified in RFC 2396 (see section 4.3. flags, first paragraph), a reference to RFC 2732 should be also added.
此规范对IPv4没有明确的依赖关系。但是，当参考RFC 2396中指定的URI格式（见第4.3节标志，第一段）时，还应添加对RFC 2732的参考。
5.155. RFC 3501: Internet Message Access Protocol - Version 4rev1
5.155. RFC 3501：Internet消息访问协议-版本4rev1
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Experimental RFCs belong to the category of "non-standard" specifications. This group involves specifications considered "off-track", e.g., specifications that haven't yet reach an adequate standardization level, or that have been superseded by more recent specifications.
实验RFC属于“非标准”规范的范畴。该组涉及被视为“偏离轨道”的规范，例如尚未达到适当标准化水平的规范，或已被较新规范取代的规范。
Experimental RFCs represent specifications that are currently part of some research effort, and that 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 of an acknowledged problem.
实验性RFC代表的规范目前是一些研究工作的一部分，通常在性质上是适当的，或者在有限的领域中使用。为了允许潜在的互操作性或其他一些潜在的有用场景，它们被记录到互联网社区中。在少数情况下，它们作为公认问题的主流解决方案的替代方案出现。
Section 3.1 (Request Messages) contains:
第3.1节（请求消息）包含：
"<Who-Anywhere-Provides?> This message parallels the <Who-Provides?> message with the "third-party" variant described above. The confirming host is required to return at least its own IP address (if it provides the named resource) as well as the IP addresses of any other hosts it believes may provide the named resource. The confirming host
“<Who Anywhere Provides？>此消息与<Who Provides？>消息类似，具有上述“第三方”变体。确认主机需要至少返回其自己的IP地址（如果提供命名资源）以及其认为可能提供命名资源的任何其他主机的IP地址。确认主机
though, may never return an IP address for a resource which is the same as an IP address listed with the resource name in the request message. In this case it must treat the resource as if it was unsupported at that IP address and omit it from any reply list.
但是，可能永远不会返回与请求消息中列出的资源名称相同的资源IP地址。在这种情况下，它必须将资源视为在该IP地址不受支持，并将其从任何回复列表中忽略。
<Does-Anyone-Provide?> This message parallels the <Do-You-Provide?> message again with the "third-party" variant described above. As before, the confirming host is required to return its own IP address as well as the IP addresses of any other hosts it believes may provide the named resource and is prohibited from returning the same IP address in the reply resource specifier as was listed in the request resource specifier. As in the <Do-You-Provide?> case and for the same reason, this message also may not be broadcast."
<Do any Provide？>此消息与<Do You Provide？>消息同样具有上述“第三方”变体。与之前一样，确认主机需要返回其自己的IP地址以及它认为可能提供命名资源的任何其他主机的IP地址，并且禁止在应答资源说明符中返回与请求资源说明符中列出的相同的IP地址。与<Do You Provide？>案例一样，出于同样的原因，此消息也可能不会广播。”
Throughout this section, there are several other references to IP address. To avoid ambiguity, a reference to IPv6 addressing should be added.
在本节中，还有其他几个关于IP地址的引用。为避免歧义，应添加对IPv6寻址的引用。
Section 4.1. (Resource Lists) presents the following qualifier format:
第4.1节。（资源列表）显示以下限定符格式：
"In addition, resource specifiers in all <Who-Anywhere-Provides?>,
<Does-Anyone-Provide?> and <They-Provide> messages also contain an
additional qualifier following the <Protocol-ID>. This qualifier
has the format
"In addition, resource specifiers in all <Who-Anywhere-Provides?>,
<Does-Anyone-Provide?> and <They-Provide> messages also contain an
additional qualifier following the <Protocol-ID>. This qualifier
has the format
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+
where
哪里
<IPLength> is the number of IP addresses containing in the following <IP-Address-List> (the <IP-Address-List> field thus occupies the last 4*<IPLength> octets in its resource specifier). In request messages, this is the maximum number of qualifying addresses which may be included in the corresponding reply resource specifier. Although not particularly useful, it may be 0 and in that case provides no space for qualifying the resource name with IP addresses in the returned specifier. In reply messages, this is the number of qualifying addresses known to provide the resource. It may not exceed the number specified in the corresponding request specifier. This field may not be 0 in a reply message unless it was supplied as 0 in
<IPLength>是包含在以下<IP地址列表>（因此<IP地址列表>字段占用其资源说明符中最后4个*<IPLength>八位字节）中的IP地址数。在请求消息中，这是可包含在相应回复资源说明符中的符合条件的地址的最大数目。虽然不是特别有用，但它可能是0，在这种情况下，在返回的说明符中没有为使用IP地址限定资源名称提供空间。在回复消息中，这是已知可提供资源的符合条件的地址数。它不能超过相应请求说明符中指定的数字。此字段在回复消息中不能为0，除非在中作为0提供
the request message and the confirming host would have returned one or more IP addresses had any space been provided.
如果提供了任何空间，请求消息和确认主机将返回一个或多个IP地址。
<IP-Address-List> is a list of four-octet IP addresses used to qualify the resource specifier with respect to those particular addresses. In reply messages, these are the IP addresses of the confirming host (when appropriate) and the addresses of any other hosts known to provide that resource (subject to the list length limitations). In request messages, these are the IP addresses of hosts for which resource information may not be returned. In such messages, these addresses should normally be initialized to some "harmless" value (such as the address of the querying host) unless it is intended to specifically exclude the supplied addresses from consideration in any reply messages."
<IP地址列表>是一个包含四个八位组IP地址的列表，用于根据这些特定地址限定资源说明符。在回复消息中，这些是确认主机的IP地址（适当时）和已知提供该资源的任何其他主机的地址（受列表长度限制）。在请求消息中，这些是可能不会返回其资源信息的主机的IP地址。在此类消息中，这些地址通常应初始化为某个“无害”值（如查询主机的地址），除非其目的是在任何回复消息中明确排除提供的地址。”
This section requires re-writing considering the 128-bit length of IPv6 addresses, and will clearly impact implementations.
考虑到IPv6地址的128位长度，本节需要重新编写，这显然会影响实现。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.3. RFC 1143: The Q Method of Implementing TELNET Option Negotiation
6.3. RFC1143：实现TELNET期权协商的Q方法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.5. RFC 1165: Network Time Protocol (NTP) over the OSI Remote Operations Service
6.5. RFC1165:OSI远程操作服务上的网络时间协议（NTP）
The only dependency this protocol presents is included in Appendix A (ROS Header Format):
本协议所呈现的唯一相关性包含在附录A（ROS标题格式）中：
"ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING
}"
"ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING
}"
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section "Protocol Specification" provides the following example, for the Initial Handshake:
“协议规范”部分为初始握手提供了以下示例：
"The ticket server replies with a "This is Your Ticket" (TIYT) packet containing the ticket. Figure 2 shows the format of this packet.
票证服务器用包含票证的“This is Your ticket”（TIYT）数据包进行回复。图2显示了该数据包的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'T' | 'I' | 'Y' | 'T' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLKSZ (by default 512) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILSZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address of CFDP server (network order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'T' | 'I' | 'Y' | 'T' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLKSZ (by default 512) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILSZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address of CFDP server (network order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2: "This Is Your Ticket" packet."
图2：“这是你的票”包
This protocol assumes IPv4 multicast, but could be converted to IPv6 multicast with a little effort.
此协议假定IPv4多播，但只需稍加努力即可转换为IPv6多播。
This protocol specifies a protocol that assumes IPv4, but does not actually have any limitations which would limit its operation in an IPv6 environment.
此协议指定了一个采用IPv4的协议，但实际上没有限制其在IPv6环境中运行的任何限制。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.12. RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited File
Transfer
6.12. RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited File
Transfer
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are only two specific IPv4 addressing references. The first is presented in Section 6.2. (Command Response):
只有两个特定的IPv4寻址引用。第一部分在第6.2节中介绍。（命令响应）：
"203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]""
"203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]""
The second appears in Section 8.12 (Configuration File):
第二个出现在第8.12节（配置文件）中：
"In specifying hostnames, both domain names and use of the 'dot' notation (127.0.0.1) should both be accepted."
在指定主机名时，应同时接受域名和使用“点”符号（127.0.0.1）
After correcting the above, IPv6 support can be added straightforwardly.
纠正上述问题后，可以直接添加IPv6支持。
6.14. RFC 1465: Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing
6.14. RFC 1465：用于静态路由的多协议/多网络环境表格式V3中X.400 MHS服务的路由协调
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.16. RFC 1528: Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures
6.16. RFC 1528:TPC.INT子域的操作原则：远程打印--技术程序
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.17. RFC 1608: Representing IP Information in the X.500 Directory
6.17. RFC 1608:表示X.500目录中的IP信息
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document defines a method for overcoming FTP IPv4 limitations and is therefore both IPv4 and IPv6 aware.
本文档定义了一种克服FTP IPv4限制的方法，因此支持IPv4和IPv6。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.22. RFC 1801: MHS use of the X.500 Directory to support MHS Routing
6.22. RFC 1801:MHS使用X.500目录支持MHS路由
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.24. RFC 1806: Communicating Presentation Information in Internet Messages: The Content-Disposition Header
6.24. RFC 1806：在Internet消息中传递表示信息：内容处置头
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.29. RFC 1986: Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol
6.29. RFC 1986：使用增强的普通文件传输协议对无线电链路的简单文件传输协议进行实验
This protocol is IPv4 dependent, as can be seen from the segment presented below, taken from Section 2. (PROTOCOL DESCRIPTION):
该协议依赖于IPv4，这可以从下面从第2节获得的段中看出。（协议说明）：
"Table 3: ETFTP Data Encapsulation
表3:ETFTP数据封装
+------------+------------+------------+------------+-----------+
|Ethernet(14)| | |ETFTP/ | |
|SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) |
|AX.25(20) | | | | |
+------------+------------+------------+------------+-----------+"
+------------+------------+------------+------------+-----------+
|Ethernet(14)| | |ETFTP/ | |
|SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) |
|AX.25(20) | | | | |
+------------+------------+------------+------------+-----------+"
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This protocol is limited to IPv4 multicast. It is expected that a similar functionality could be implemented on top of IPv6 multicast.
此协议仅限于IPv4多播。预计类似的功能可以在IPv6多播之上实现。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.36. RFC 2162: MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail
6.36. RFC 2162:MaXIM-11-X.400/互联网邮件和mail-11邮件之间的映射
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.37. RFC 2169: A Trivial Convention for using HTTP in URN Resolution
6.37. RFC2169：在URN解析中使用HTTP的简单约定
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.40. RFC 2296: HTTP Remote Variant Selection Algorithm RVSA/1.0
6.40. RFC2296:HTTP远程变量选择算法RVSA/1.0
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.41. RFC 2307: An Approach for Using LDAP as a Network Information Service
6.41. RFC2307：一种将LDAP用作网络信息服务的方法
This protocol assumes IPv4 addressing in its schema, as shown in Section 3. (Attribute definitions):
此协议在其模式中采用IPv4寻址，如第3节所示。（属性定义）：
"( nisSchema.1.19 NAME 'ipHostNumber' DESC 'IP address as a dotted decimal, eg. 192.168.1.1, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' )
“（nisSchema.1.19将'ipHostNumber'DESC'IP地址命名为点十进制，例如192.168.1.1，省略前导零'EQUALITY CaseIgnoreA5Match语法'IA5String{128}'）
( nisSchema.1.20 NAME 'ipNetworkNumber' DESC 'IP network as a dotted decimal, eg. 192.168, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' SINGLE-VALUE )
（nisSchema.1.20将'ipNetworkNumber'DESC'IP网络命名为点十进制，例如192.168，省略前导零'EQUALITY CaseIgnoreA5Match语法'IA5String{128}'单值）
( nisSchema.1.21 NAME 'ipNetmaskNumber' DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' SINGLE-VALUE )"
（nisSchema.1.21将'ipNetmaskNumber'DESC'IP网络掩码命名为点十进制，例如255.255.255.0，省略前导零'EQUALITY CaseIgnoreA5Match语法'IA5String{128}'单值）
The document does try to provide some IPv6 support as in Section 5.4. (Interpreting Hosts and Networks):
本文档试图提供一些IPv6支持，如第5.4节所述。（解释主机和网络）：
"Hosts with IPv6 addresses MUST be written in their "preferred" form as defined in section 2.2.1 of [RFC1884], such that all components of the address are indicated and leading zeros are omitted. This provides a consistent means of resolving ipHosts by address."
具有IPv6地址的主机必须以[RFC1884]第2.2.1节中定义的“首选”形式写入，以便指示地址的所有组件并省略前导零。这提供了按地址解析IPHOST的一致方法
However, the defined format mentioned above has been replaced, hence it is no longer valid.
但是，上述定义的格式已被替换，因此不再有效。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.43. RFC 2483: URI Resolution Services Necessary for URN Resolution
6.43. RFC 2483:URN解析所需的URI解析服务
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.45. RFC 2568: Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol
6.45. RFC 2568：互联网打印协议模型和协议结构的基本原理
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.47. RFC 2649: An LDAP Control and Schema for Holding Operation Signatures
6.47. RFC2649：用于保存操作签名的LDAP控件和模式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.48. RFC 2654: A Tagged Index Object for use in the Common Indexing Protocol
6.48. RFC 2654：用于公共索引协议的标记索引对象
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This specification claims to be both IPv4 and IPv6 aware, but in Section 2.8. (An HTCP/0.0 AUTH has the following structure), it makes the following statement:
本规范声称同时支持IPv4和IPv6，但在第2.8节中。（HTCP/0.0认证具有以下结构），它做出以下声明：
"SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see [RFC 2104]), with a B value of 64, of the following elements, each of which is digested in its "on the wire" format, including transmitted padding if any is covered by a field's associated LENGTH:
“签名是一个COUNTSTR[3.1]，它保存以下元素的HMAC-MD5摘要（见[RFC 2104]），B值为64，每个元素都以其“在线”格式进行摘要，包括传输的填充（如果字段的相关长度包含任何填充）：
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]"
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]"
The given SIGNATURE calculation should be expanded to support IPv6 16 byte addresses.
给定的签名计算应扩展为支持IPv6 16字节地址。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This protocol is both IPv4 and IPv6 aware and needs no changes.
此协议支持IPv4和IPv6，无需更改。
In section 3.4 (Address Formats), there are explicit references to IPv4 addressing:
在第3.4节（地址格式）中，明确提到了IPv4地址：
"The following address format numbers are definite for nodes, immediately connected to the global IPv4 network:
“对于立即连接到全局IPv4网络的节点，以下地址格式编号是确定的：
N 4-0-0 (4) N 4-0-1 (4-1) N 4-0-2 (4-2)
n4-0-0（4）n4-0-1（4-1）n4-0-2（4-2）
The appropriate formats of 128-bit addresses:
128位地址的适当格式：
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Free
自由的
It is not used by the protocol.
协议没有使用它。
IP address
IP地址
It sets the node address in the global IPv4 network."
它设置全局IPv4网络中的节点地址。”
This section needs to be re-written, so that the specification becomes IPv6 compliant.
本节需要重新编写，以便规范与IPv6兼容。
This protocol is both IPv4 and IPv6 aware, and thus requires no changes.
此协议同时支持IPv4和IPv6，因此不需要更改。
6.57. RFC 3088: OpenLDAP Root Service An experimental LDAP referral service
6.57. RFC3088:OpenLDAP根服务一个实验性的LDAP引用服务
Section 5. (Using the Service) states:
第5节。（使用服务）声明：
"The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over
TCP/IPv4. Future incarnations of this service may support
TCP/IPv6 or other transport/internet protocols."
"The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over
TCP/IPv4. Future incarnations of this service may support
TCP/IPv6 or other transport/internet protocols."
This survey contemplates 257 RFCs, having 34 (12.84%) been identified as having some form of IPv4 dependency. Results are broken down as follows:
这项调查考虑了257个RFC，其中34个（12.84%）被确定具有某种形式的IPv4依赖性。结果细分如下：
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%
Of the 33 identified, the majority simply require minor actions, such as adding a caveat to IPv6 addressing that would avoid ambiguity, or re-writing a section to avoid IP-version dependent syntax. The remaining instances are documented below. The authors have attempted to organize the results in a format that allows easy referencing by other protocol designers.
在已确定的33项中，大多数只需要采取一些小动作，例如为IPv6寻址添加一条警告，以避免歧义，或者重新编写一节以避免依赖于IP版本的语法。其余实例记录如下。作者试图以一种便于其他协议设计者参考的格式组织结果。
Problems have already been fixed in [5].
问题已在[5]中解决。
7.2.1. RFC 1305: Network Time Protocol (version 3): Specification, Implementation and Analysis
7.2.1. RFC1305：网络时间协议（版本3）：规范、实现和分析
As documented in Section 4.4. above, there are too many specific references to the use of 32-bit IPv4 addresses. An updated specification to support NTP over IPv6 is needed. However, there has been some work related with this issue, as an already expired
如第4.4节所述。上面，有太多具体的参考使用32位IPv4地址。需要更新规范以支持IPv6上的NTP。然而，已经有一些与这个问题相关的工作，因为一个已经过期的版本
work in progress, allegedly documents. Also, there is at least one IPv6 NTP implementation.
正在进行的工作，据称是文件。此外，至少有一个IPv6 NTP实现。
URI's allow the literal use of IPv4 addresses but have no specific recommendations on how to represent literal IPv6 addresses. This problem has already been addressed in [3].
URI允许IPv4地址的文字使用，但没有关于如何表示文字IPv6地址的具体建议。这个问题已经在[3]中得到了解决。
HTTP allows the literal use of IPv4 addresses, but has no specific recommendations on how to represent literal IPv6 addresses. This problem has already been addressed in [3].
HTTP允许IPv4地址的文字使用，但没有关于如何表示文字IPv6地址的具体建议。这个问题已经在[3]中得到了解决。
There is a dependency in the definition of the TTYLOC Number which would require an updated version of the protocol. However, since this functionality is of marginal value today, an updated version might not make sense.
TTYLOC编号的定义中存在依赖关系，需要更新协议版本。但是，由于该功能在今天的价值微乎其微，因此更新版本可能没有意义。
URL's with IPv4 dependencies have already been addressed in [3].
[3]中已经解决了具有IPv4依赖关系的URL。
Note that these dependencies affect other specifications as well, such as RFC 2122, RFC 2192, RFC 2193, RFC 2255, RFC 2371, and RFC 2384. All of these protocols have to revisited, and are not described separately in this memo.
请注意，这些依赖关系也会影响其他规范，例如RFC 2122、RFC 2192、RFC 2193、RFC 2255、RFC 2371和RFC 2384。所有这些协议都必须重新审查，本备忘录中没有单独描述。
The problems of this specification have already been addressed in [4].
本规范的问题已在[4]中解决。
POP URL IPv4 dependencies have already been addressed in [3].
[3]中已解决了POP URL IPv4依赖关系。
The problems of this specification have already been addressed in [4].
本规范的问题已在[4]中解决。
Some textual updates and clarifications to MX processing would likely be useful. The operational scenarios and guidelines to avoid the problems have been described in [6].
对MX处理进行一些文本更新和澄清可能会有用。[6]中描述了避免问题的操作场景和指南。
Extensions should be defined to support IPv6 addresses.
应定义扩展以支持IPv6地址。
The packet format of this protocol depends on IPv4, and would require updating to add IPv6 support. However, the protocol is not believed to be in use, so such an update may not be warranted.
此协议的数据包格式取决于IPv4，需要更新以添加IPv6支持。但是，据信该协议未在使用中，因此可能不保证进行此类更新。
This specification only requires a text update to become IPv6 compliant.
此规范只需要文本更新即可兼容IPv6。
This specification only requires a text update to become IPv6 compliant.
此规范只需要文本更新即可兼容IPv6。
This protocol relies on IPv4 IGMP Multicast. To become IPv6 compliant, a new version should be produced.
此协议依赖于IPv4 IGMP多播。要符合IPv6，应生产新版本。
This document tries to provide IPv6 support but it relies on an outdated format for IPv6 addresses. Thus, there is the need for an IPv6 compliant version.
本文档试图提供IPv6支持，但它依赖于IPv6地址的过时格式。因此，需要一个兼容IPv6的版本。
Phil would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally, Phil would like to thank his partner in all ways, Wendy M. Nesser.
Phil感谢互联网协会在本文件的研究和制作过程中给予的支持。此外，菲尔还要感谢他的合作伙伴温迪·M·内瑟。
This document provides an exhaustive documentation of current IETF documented standards IPv4 address dependencies. Such process does not have security implications in itself.
本文档提供了当前IETF文档化标准IPv4地址依赖性的详尽文档。这一进程本身并不涉及安全问题。
[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] Bradner, S., "The Internet Standards Process - version 3", BCP 9, RFC 2026, October 1996.
[2] Bradner，S.，“互联网标准过程-第3版”，BCP 9，RFC 2026，1996年10月。
[3] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[3] Hinden，R.，Carpenter，B.和L.Masinter，“URL中文字IPv6地址的格式”，RFC 2732，1999年12月。
[4] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001.
[4] Guttman，E.，“IPv6的服务位置协议修改”，RFC 3111，2001年5月。
[5] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[5] Allman，M.，Ostermann，S.和C.Metz，“IPv6和NAT的FTP扩展”，RFC24281998年9月。
[6] Hagino, J. and M. Nakamura, "SMTP operational experience in mixed IPv4/IPv6 environements", Work in Progress.
[6] Hagino，J.和M.Nakamura，“IPv4/IPv6混合环境中的SMTP操作经验”，正在进行中。
Rute Sofia FCCN Av. Brasil, 101 1700 Lisboa, Portugal
鲁特索菲亚FCCN Av。葡萄牙里斯本，巴西，101 1700
Phone: +351 91 2507372
EMail: rsofia@zmail.pt
Phone: +351 91 2507372
EMail: rsofia@zmail.pt
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
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编辑功能的资金目前由互联网协会提供。