Network Working Group P. Nesser, II
Request for Comments: 3794 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Network Working Group P. Nesser, II
Request for Comments: 3794 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents
当前部署的IETF传输区标准跟踪和实验文档中IPv4地址的调查
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
本文档旨在记录当前部署的IETF传输区域文件化标准中IPv4地址的所有使用情况。为了成功地从全IPv4 Internet过渡到全IPv6 Internet，将采取许多临时步骤。其中一个步骤是发展具有IPv4依赖关系的当前协议。人们希望这些协议（及其实现）将被重新设计为与网络地址无关，但如果不能做到这一点，则至少会同时支持IPv4和IPv6。为此，将调查所有标准（完整、草案和提议）以及实验性RFC，并记录任何相关性。
Table of Contents
目录
1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0. Document Organization. . . . . . . . . . . . . . . . . . . . 2
3.0. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 2
4.0. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . 10
5.0. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 11
6.0. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 22
7.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 27
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . 27
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . 27
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . 29
8.0. Security Considerations. . . . . . . . . . . . . . . . . . . 30
9.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0. Document Organization. . . . . . . . . . . . . . . . . . . . 2
3.0. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 2
4.0. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . 10
5.0. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 11
6.0. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 22
7.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 27
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . 27
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . 27
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . 29
8.0. Security Considerations. . . . . . . . . . . . . . . . . . . 30
9.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
10.0. Normative Reference. . . . . . . . . . . . . . . . . . . . . 30
11.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
12.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
10.0. Normative Reference. . . . . . . . . . . . . . . . . . . . . 30
11.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
12.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
This document is part of a document set aiming to document all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents conforming to the current IETF areas (Application, Internet, Operations & Management, Routing, Security, Sub-IP and Transport).
本文档是旨在记录IETF标准中IPv4地址的所有使用情况的文档集的一部分。为了使信息具有可管理的形式，已将其分为符合当前IETF领域（应用、互联网、运营与管理、路由、安全、子IP和传输）的7个文件。
For a full introduction, please see the introduction [1].
有关完整的介绍，请参见介绍[1]。
The rest of the document sections are described below.
文档的其余部分如下所述。
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, and Proposed Standards, and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending with (around) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if the problems have already been fixed.
第3节、第4节、第5节和第6节分别描述了完整、草案和拟议标准以及实验RFC的原始分析。依次讨论每个RFC，从RFC 1开始，到RFC 3100结束。每个RFC的注释本质上是“原始”的。也就是说，每个RFC都是在真空中讨论的，所讨论的问题不会“向前看”，看问题是否已经解决。
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated.
第7节是对第3、4、5和6节中提供的数据的分析。正是在这里，所有的结果都被视为一个整体，并且在以后的RFC中解决的问题被关联起来。
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完整的互联网标准（通常简称为“标准”）是在整个互联网上广泛实施和使用的完全成熟的协议规范。
Although UDP is a transport protocol there is one reference to the UDP/IP interface that states; "The UDP module must be able to determine the source and destination internet addresses and the protocol field from the internet header." This does not force a rewrite of the protocol but will clearly cause changes in implementations.
虽然UDP是一种传输协议，但有一个对UDP/IP接口的引用，其中指出：；“UDP模块必须能够从internet报头确定源和目标internet地址以及协议字段。”这不会强制重写协议，但显然会导致实现的更改。
Section 3.1 which specifies the header format for TCP. The TCP header is free from IPv4 references but there is an inconsistency in the computation of checksums. The text says: "The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length." The first and second 32-bit words are clearly meant to specify 32-bit IPv4 addresses. While no modification of the TCP protocol is necessitated by this problem, an alternate needs to be specified as an update document, or as part of another IPv6 document.
第3.1节规定了TCP的标头格式。TCP标头没有IPv4引用，但校验和的计算不一致。正文中说：“校验和还包括一个96位伪头，在概念上是TCP头的前缀。这个伪头包含源地址、目标地址、协议和TCP长度。”第一个和第二个32位字显然是用来指定32位IPv4地址的。虽然此问题不需要修改TCP协议，但需要将备用协议指定为更新文档或另一个IPv6文档的一部分。
This is a layer 3 protocol, and has as such no IPv4 dependencies.
这是一个第3层协议，因此没有IPv4依赖项。
3.4.1. RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS
3.4.1. TCP/UDP传输上NetBIOS服务的RFC 1001协议标准：概念和方法
Section 15.4.1. RELEASE BY B NODES defines:
第15.4.1节。B节点发布定义：
A NAME RELEASE DEMAND contains the following information:
名称发布请求包含以下信息：
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID
- NetBIOS名称—NetBIOS名称的范围—名称类型：唯一或组—发布节点的IP地址—事务ID
Section 15.4.2. RELEASE BY P NODES defines:
第15.4.2节。按P节点发布定义：
A NAME RELEASE REQUEST contains the following information:
姓名发布请求包含以下信息：
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID
- NetBIOS名称—NetBIOS名称的范围—名称类型：唯一或组—发布节点的IP地址—事务ID
A NAME RELEASE RESPONSE contains the following information:
名称发布响应包含以下信息：
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID - Result: - Yes: name was released - No: name was not released, a reason code is provided
- NetBIOS名称-NetBIOS名称的范围-名称类型：唯一或组-发布节点的IP地址-事务ID-结果：-是：名称已发布-否：名称未发布，提供原因代码
Section 16. NetBIOS SESSION SERVICE states:
第16节。NetBIOS会话服务状态：
The NetBIOS session service begins after one or more IP addresses have been found for the target name. These addresses may have been acquired using the NetBIOS name query transactions or by other means, such as a local name table or cache.
NetBIOS会话服务在为目标名称找到一个或多个IP地址后开始。这些地址可能是使用NetBIOS名称查询事务或通过其他方式（如本地名称表或缓存）获取的。
Section 16.1. OVERVIEW OF NetBIOS SESSION SERVICE
第16.1节。NetBIOS会话服务概述
Session service has three phases:
会话服务分为三个阶段：
Session establishment - it is during this phase that the IP address and TCP port of the called name is determined, and a TCP connection is established with the remote party.
会话建立-在此阶段确定被叫名称的IP地址和TCP端口，并与远程方建立TCP连接。
6.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW
6.1.1. 会话建立阶段概述
An end-node begins establishment of a session to another node by somehow acquiring (perhaps using the name query transactions or a local cache) the IP address of the node or nodes purported to own the destination name.
终端节点通过某种方式获取（可能使用名称查询事务或本地缓存）声称拥有目的地名称的一个或多个节点的IP地址，开始建立与另一个节点的会话。
Once the TCP connection is open, the calling node sends session service request packet. This packet contains the following information:
一旦TCP连接打开，调用节点将发送会话服务请求数据包。此数据包包含以下信息：
- Calling IP address (see note) - Calling NetBIOS name - Called IP address (see note) - Called NetBIOS name
- 调用IP地址（请参见备注）-调用NetBIOS名称-调用IP地址（请参见备注）-调用NetBIOS名称
NOTE: The IP addresses are obtained from the TCP service interface.
注意：IP地址是从TCP服务接口获得的。
If a compatible LISTEN exists, and there are adequate resources, then the session server may transform the existing TCP connection into the NetBIOS data session. Alternatively, the session server may redirect, or "retarget" the caller to another TCP port (and IP address).
如果存在兼容的侦听，并且有足够的资源，则会话服务器可以将现有TCP连接转换为NetBIOS数据会话。或者，会话服务器可以将调用者重定向或“重定目标”到另一个TCP端口（和IP地址）。
If the caller is redirected, the caller begins the session establishment anew, but using the new IP address and TCP port given in the retarget response. Again a TCP connection is created, and again the calling and called node exchange credentials. The called party may accept the call, reject the call, or make a further redirection.
如果调用者被重定向，调用者将使用重定目标响应中给出的新IP地址和TCP端口重新开始会话建立。再次创建TCP连接，并再次交换调用和被调用节点的凭据。被叫方可以接受呼叫、拒绝呼叫或进行进一步的重定向。
17.1. OVERVIEW OF NetBIOS DATAGRAM SERVICE
17.1. NetBIOS数据报服务概述
Every NetBIOS datagram has a named destination and source. To transmit a NetBIOS datagram, the datagram service must perform a name query operation to learn the IP address and the attributes of the destination NetBIOS name. (This information may be cached to avoid the overhead of name query on subsequent NetBIOS datagrams.)
每个NetBIOS数据报都有一个命名的目标和源。要传输NetBIOS数据报，数据报服务必须执行名称查询操作，以了解IP地址和目标NetBIOS名称的属性。（可以缓存此信息，以避免后续NetBIOS数据报上的名称查询开销。）
17.1.1. UNICAST, MULTICAST, AND BROADCAST
17.1.1. 单播、多播和广播
NetBIOS datagrams may be unicast, multicast, or broadcast. A NetBIOS datagram addressed to a unique NetBIOS name is unicast. A NetBIOS datagram addressed to a group NetBIOS name, whether there are zero, one, or more actual members, is multicast. A NetBIOS datagram sent using the NetBIOS "Send Broadcast Datagram" primitive is broadcast.
NetBIOS数据报可以是单播、多播或广播。指向唯一NetBIOS名称的NetBIOS数据报为单播。寻址到组NetBIOS名称的NetBIOS数据报（无论是否有零个、一个或多个实际成员）是多播的。使用NetBIOS“发送广播数据报”原语发送的NetBIOS数据报被广播。
17.1.2. FRAGMENTATION OF NetBIOS DATAGRAMS
17.1.2. NetBIOS数据报的碎片化
When the header and data of a NetBIOS datagram exceeds the maximum amount of data allowed in a UDP packet, the NetBIOS datagram must be fragmented before transmission and reassembled upon receipt.
当NetBIOS数据报的报头和数据超过UDP数据包中允许的最大数据量时，NetBIOS数据报必须在传输前进行分段，并在接收时重新组装。
A NetBIOS Datagram is composed of the following protocol elements:
NetBIOS数据报由以下协议元素组成：
- IP header of 20 bytes (minimum) - UDP header of 8 bytes - NetBIOS Datagram Header of 14 bytes - The NetBIOS Datagram data.
- IP头为20字节（最小）-UDP头为8字节-NetBIOS数据报头为14字节-NetBIOS数据报数据。
18. NODE CONFIGURATION PARAMETERS
18. 节点配置参数
- B NODES: - Node's permanent unique name - Whether IGMP is in use - Broadcast IP address to use - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation) - P NODES: - Node's permanent unique name - IP address of NBNS - IP address of NBDD - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation) - M NODES: - Node's permanent unique name - Whether IGMP is in use - Broadcast IP address to use - IP address of NBNS - IP address of NBDD - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation)
- B节点：-节点的永久唯一名称-是否使用IGMP-要使用的广播IP地址-是否需要NetBIOS会话保持有效-可用UDP数据字段长度（用于控制碎片）-P节点：-节点的永久唯一名称-NBN的IP地址-NBDD的IP地址-是否需要NetBIOS会话保持有效-可用UDP数据字段长度（用于控制碎片）-M节点：-节点的永久唯一名称-是否使用IGMP-要使用的广播IP地址-NBN的IP地址-NBDD的IP地址-是否需要NetBIOS会话保持有效-可用UDP数据字段长度（用于控制碎片）
All of the proceeding sections make implicit use of IPv4 addresses and a new specification should be defined for use of IPv6 underlying addresses.
前面的所有部分都隐式使用IPv4地址，应该为IPv6基础地址的使用定义一个新的规范。
3.4.2. RFC 1002 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS
3.4.2. TCP/UDP传输上NetBIOS服务的RFC 1002协议标准：详细规范
Section 4.2.1.3. RESOURCE RECORD defines
第4.2.1.3节。资源记录定义
RESOURCE RECORD RR_TYPE field definitions:
资源记录RR_类型字段定义：
Symbol Value Description:
符号值说明：
A 0x0001 IP address Resource Record (See REDIRECT NAME QUERY RESPONSE)
0x0001 IP地址资源记录（请参阅重定向名称查询响应）
Sections 4.2.2. NAME REGISTRATION REQUEST, 4.2.3. NAME OVERWRITE REQUEST & DEMAND, 4.2.4. NAME REFRESH REQUEST, 4.2.5. POSITIVE NAME REGISTRATION RESPONSE, 4.2.6. NEGATIVE NAME REGISTRATION RESPONSE, 4.2.7. END-NODE CHALLENGE REGISTRATION RESPONSE, 4.2.9. NAME RELEASE REQUEST & DEMAND, 4.2.10. POSITIVE NAME RELEASE RESPONSE, 4.2.11. NEGATIVE NAME RELEASE RESPONSE and Sections 4.2.13. POSITIVE NAME QUERY
第4.2.2节。姓名注册申请，4.2.3。名称覆盖请求和需求，4.2.4。名称刷新请求，4.2.5。正面姓名注册响应，4.2.6。否定姓名注册响应，4.2.7。终端节点质询注册响应，4.2.9。名称发布请求和需求，4.2.10。正面名称发布响应，4.2.11。负面名称发布响应和第4.2.13节。正名查询
RESPONSE all contain 32 bit fields labeled "NB_ADDRESS" clearly defined for IPv4 addresses Sections 4.2.15. REDIRECT NAME QUERY RESPONSE contains a field "NSD_IP_ADDR" which also is designed for a IPv4 address.
所有响应都包含标记为“NB_地址”的32位字段，这些字段在第4.2.15节中为IPv4地址明确定义。重定向名称查询响应包含一个字段“NSD_IP_ADDR”，该字段也是为IPv4地址设计的。
Section 4.3.5. SESSION RETARGET RESPONSE PACKET
第4.3.5节。会话重定目标响应包
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETARGET_IP_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETARGET_IP_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.1. NetBIOS DATAGRAM HEADER
第4.4.1节。NetBIOS数据报报头
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST DATAGRAM
第4.4.2节。DIRECT_唯一、DIRECT_组和广播数据报
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ SOURCE_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ SOURCE_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.3. DATAGRAM ERROR PACKET
第4.4.3节。数据报错误包
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.4. DATAGRAM QUERY REQUEST
第4.4.4节。数据报查询请求
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.5. DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE
4.4.5. 数据报正反查询响应
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. NetBIOS DATAGRAM SERVICE PROTOCOLS
5.3. NetBIOS数据报服务协议
The following are GLOBAL variables and should be NetBIOS user configurable:
以下是全局变量，应为NetBIOS用户配置：
- BROADCAST_ADDRESS: the IP address B-nodes use to send datagrams with group name destinations and broadcast datagrams. The default is the IP broadcast address for a single IP network.
- 广播地址：IP地址B节点用于发送带有组名目的地和广播数据报的数据报。默认为单个IP网络的IP广播地址。
There is also a large amount of pseudo code for most of the protocols functionality that make no specific reference to IPv4 addresses. However they assume the use of the above defined packets. The pseudo code may be valid for IPv6 as long as the packet formats are updated.
对于大多数协议功能，也有大量的伪代码，它们没有特定地引用IPv4地址。但是，它们假定使用上述定义的数据包。只要数据包格式得到更新，伪代码就可能对IPv6有效。
Section 5. The Protocol defines a mapping specification
第5节。协议定义了一个映射规范
Mapping parameters is also straight-forward:
映射参数也很简单：
network service TCP
------- ---
CONNECTION RELEASE
network service TCP
------- ---
CONNECTION RELEASE
Called address server's IP address (4 octets)
被叫地址服务器的IP地址（4个八位字节）
Calling address client's IP address (4 octets)
呼叫地址客户端的IP地址（4个八位字节）
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
标准草案代表IETF中倒数第二个标准级别。只有当存在多个独立的、可互操作的实现时，协议才能实现标准草案。标准草案通常是相当成熟和广泛使用的。
4.1. RFC 3530 Network File System (NFS) version 4 Protocol
4.1. RFC 3530网络文件系统（NFS）版本4协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.2. RFC 3550 RTP: A Transport Protocol for Real-Time Applications
4.2. RFC350RTP：一种用于实时应用的传输协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.3. RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control.
4.3. RFC 3551 RTP配置文件，用于音频和视频会议，控制最少。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases Proposed are never implemented or advanced in the IETF standards process. They therefore are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion.
拟议标准是介绍性文件。即使是单个实现也没有要求。在许多情况下，在IETF标准过程中从未实施或推进提议。因此，它们通常只是向互联网社区提出的想法。有时缺陷会暴露出来，或者是许多相互竞争的问题解决方案之一。在后一种情况下，不进行讨论，因为这不符合本次讨论的目的。
5.01. RFC 1144 Compressing TCP/IP headers for low-speed serial links
5.01. RFC 1144压缩低速串行链路的TCP/IP头
This RFC is specifically oriented towards TCP/IPv4 packet headers and will not work in it's current form. Significant work has already been done on similar algorithms for TCP/IPv6 headers.
此RFC专门面向TCP/IPv4数据包头，不会以其当前形式工作。关于TCP/IPv6报头的类似算法已经做了大量工作。
5.02. RFC 1323 TCP Extensions for High Performance
5.02. RFC 1323高性能TCP扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.03. RFC 1553 Compressing IPX Headers Over WAN Media (CIPX)
5.03. RFC 1553通过WAN媒体（CIPX）压缩IPX头
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.04. RFC 1692 Transport Multiplexing Protocol (TMux)
5.04. RFC 1692传输多路复用协议（TMux）
Section 6. Implementation Notes is states:
第6节。执行说明如下：
Because the TMux mini-header does not contain a TOS field, only segments with the same IP TOS field should be contained in a single TMux message. As most systems do not use the TOS feature, this is not a major restriction. Where the TOS field is used, it may be desirable to hold several messages under construction for a host, one for each TOS value.
由于TMux最小标头不包含TOS字段，因此单个TMux消息中只应包含具有相同IP TOS字段的段。由于大多数系统不使用TOS功能，这不是主要限制。在使用TOS字段的情况下，可能需要为主机保存多个正在构造的消息，每个TOS值对应一个消息。
Segments containing IP options should not be multiplexed.
包含IP选项的段不应多路复用。
This is clearly IPv4 specific, but a simple restatement in IPv6 terms will allow complete functionality.
这显然是特定于IPv4的，但简单地重述IPv6术语将允许完整的功能。
5.05. RFC 1831 RPC: Remote Procedure Call Protocol Specification Version 2 RPC
5.05. RFC 1831 RPC:远程过程调用协议规范版本2 RPC
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.06. RFC 1833 Binding Protocols for ONC RPC Version 2
5.06. 用于ONC RPC版本2的RFC 1833绑定协议
In Section 2.1 RPCBIND Protocol Specification (in RPC Language) there is the following code fragment:
在第2.1节RPCBIND协议规范（RPC语言）中，有以下代码片段：
* Protocol family (r_nc_protofmly): * This identifies the family to which the protocol belongs. * The following values are defined: * NC_NOPROTOFMLY "-" * NC_LOOPBACK "loopback" * NC_INET "inet" * NC_IMPLINK "implink" * NC_PUP "pup" * NC_CHAOS "chaos" * NC_NS "ns" * NC_NBS "nbs" * NC_ECMA "ecma" * NC_DATAKIT "datakit" * NC_CCITT "ccitt" * NC_SNA "sna" * NC_DECNET "decnet" * NC_DLI "dli" * NC_LAT "lat" * NC_HYLINK "hylink" * NC_APPLETALK "appletalk" * NC_NIT "nit" * NC_IEEE802 "ieee802" * NC_OSI "osi" * NC_X25 "x25" * NC_OSINET "osinet" * NC_GOSIP "gosip"
* 协议族（r_nc_protofmly）：*这标识协议所属的族。*定义了以下值：*NC_NOPROTOFMLY“-”*NC_LOOPBACK“LOOPBACK”*NC_INET“INET”*NC_IMPLINK“IMPLINK”*NC_PUP“PUP”*NC_NS“NS”*NC_NBS“NBS”*NC_ECMA“ECMA”*NC_数据包“DATAKIT”*NC_CCITT“CCITT”*NC_SNA“SNA”*NC_decnc decne“decne”*NC_DLI“DLI”*NC_latu“applylink”“appletalk”*NC_NIT“NIT”*NC_IEEE802“IEEE802”*NC_OSI“OSI”*NC_X25“X25”*NC_OSIET“OSIET”*NC_GOSIP“GOSIP”
It is clear that the value for NC_INET is intended for the IP protocol and is seems clear that it is IPv4 dependent.
很明显，NC_INET的值是用于IP协议的，并且它显然依赖于IPv4。
5.07. RFC 1962 The PPP Compression Control Protocol (CCP)
5.07. RFC 1962 PPP压缩控制协议（CCP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.08. RFC 2018 TCP Selective Acknowledgement Options
5.08. RFC 2018 TCP选择性确认选项
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.09. RFC 2029 RTP Payload Format of Sun's CellB Video Encoding
5.09. Sun CellB视频编码的RFC 2029 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.10. RFC 2032 RTP Payload Format for H.261 Video Streams
5.10. 用于H.261视频流的RFC 2032 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.11. RFC 2126 ISO Transport Service on top of TCP (ITOT)
5.11. TCP之上的RFC 2126 ISO传输服务（ITOT）
This specification is IPv6 aware and has no issues.
此规范支持IPv6，没有任何问题。
5.12. RFC 2190 RTP Payload Format for H.263 Video Streams
5.12. 用于H.263视频流的RFC 2190 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.13. RFC 2198 RTP Payload for Redundant Audio Data
5.13. RFC 2198冗余音频数据的RTP有效负载
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.14. RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
5.14. RFC 2205资源预留协议（RSVP）——第1版功能规范
In Section 1. Introduction the statement is made:
在第1节中。引言发言如下：
RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack.
RSVP在IPv4或IPv6之上运行，在协议栈中占据传输协议的位置。
Appendix A defines all of the header formats for RSVP and there are multiple formats for both IPv4 and IPv6.
附录A定义了RSVP的所有报头格式，IPv4和IPv6都有多种格式。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.15. RFC 2207 RSVP Extensions for IPSEC Data Flows
5.15. 用于IPSEC数据流的RFC 2207 RSVP扩展
The defined IPsec extensions are valid for both IPv4 & IPv6. There are no IPv4 dependencies in this specification.
定义的IPsec扩展对IPv4和IPv6都有效。此规范中不存在IPv4依赖项。
5.16. RFC 2210 The Use of RSVP with IETF Integrated Services
5.16. RFC 2210将RSVP与IETF集成服务结合使用
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.17. RFC 2211 Specification of the Controlled-Load Network Element Service
5.17. RFC 2211受控负载网元服务规范
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.18. RFC 2212 Specification of Guaranteed Quality of Service
5.18. RFC 2212保证服务质量规范
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.19. RFC 2215 General Characterization Parameters for Integrated Service Network Elements
5.19. RFC 2215综合业务网元的一般特征参数
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.20. RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video
5.20. 用于MPEG1/MPEG2视频的RFC 2250 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.21. RFC 2326 Real Time Streaming Protocol (RTSP)
5.21. RFC 2326实时流协议（RTSP）
Section 3.2 RTSP URL defines:
第3.2节RTSP URL定义了：
The "rtsp" and "rtspu" schemes are used to refer to network resources via the RTSP protocol. This section defines the scheme-specific syntax and semantics for RTSP URLs.
“rtsp”和“rtspu”方案用于通过rtsp协议引用网络资源。本节定义RTSP URL的特定于方案的语法和语义。
rtsp_URL = ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP
address (in dotted decimal form), as defined
by Section 2.1 of RFC 1123 \cite{rfc1123}>
port = *DIGIT
rtsp_URL = ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP
address (in dotted decimal form), as defined
by Section 2.1 of RFC 1123 \cite{rfc1123}>
port = *DIGIT
Although later in that section the following text is added:
尽管本节后面增加了以下内容：
The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1924 [19]).
应尽可能避免在URL中使用IP地址（见RFC 1924[19]）。
Some later examples show:
后面的一些示例显示：
Example:
例子：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl,
application/mheg
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl,
application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol
v=0 o=mhandley 2890844526 IP4中的2890842807 126.16.64.4 s=SDP研讨会i=关于会话描述协议的研讨会
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
which implies the use of the "IP4" tag and it should be possible to use an "IP6" tag. There are also numerous other similar examples using the "IP4" tag.
这意味着使用“IP4”标签，并且应该可以使用“IP6”标签。还有许多使用“IP4”标记的其他类似示例。
RTSP is also dependent on IPv6 support in a protocol capable of describing media configurations, for example SDP RFC 2327.
RTSP还依赖于能够描述媒体配置的协议中的IPv6支持，例如SDP RFC 2327。
RTSP can be used over IPv6 as long as the media description protocol supports IPv6, but only for certain restricted use cases. For full functionality there is need for IPv6 support. The amount of updates needed are small.
只要媒体描述协议支持IPv6，RTSP就可以在IPv6上使用，但只能用于某些受限的用例。要实现完整功能，需要IPv6支持。所需的更新量很小。
5.22. RFC 2327 SDP: Session Description Protocol (SDP)
5.22. RFC 2327 SDP：会话描述协议（SDP）
This specification is under revision, and IPv6 support was added in RFC 3266 which updates this specification.
本规范正在修订中，RFC 3266中添加了IPv6支持，更新了本规范。
5.23. RFC 2380 RSVP over ATM Implementation Requirements
5.23. RFC 2380基于ATM的RSVP实施要求
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.24. RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM
5.24. RFC 2381受控负载服务和保证服务与ATM的互操作
There does not seem any inherent IPv4 limitations in this specification, but it assumes work of other standards that have IPv4 limitations.
本规范中似乎没有任何固有的IPv4限制，但它假定其他标准具有IPv4限制。
5.25. RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
5.25. 1998版ITU-T Rec.H.263视频（H.263+）的RFC 2429 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.26. RFC 2431 RTP Payload Format for BT.656 Video Encoding
5.26. 用于BT.656视频编码的RFC 2431 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.27. RFC 2435 RTP Payload Format for JPEG-compressed Video
5.27. 用于JPEG压缩视频的RFC 2435 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.28. RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
5.28. RFC 2474 IPv4和IPv6标头中区分服务字段（DS字段）的定义
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.29. RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
5.29. RFC 2508压缩低速串行链路的IP/UDP/RTP报头
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.30. RFC 2581 TCP Congestion Control
5.30. RFC 2581 TCP拥塞控制
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.31. RFC 2597 Assured Forwarding PHB Group
5.31. RFC 2597保证转发PHB组
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.32. RFC 2658 RTP Payload Format for PureVoice(tm) Audio
5.32. 用于PureVoice（tm）音频的RFC 2658 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.33. RFC 2678 IPPM Metrics for Measuring Connectivity
5.33. RFC 2678测量连接性的IPPM指标
This specification only supports IPv4.
此规范仅支持IPv4。
5.34. RFC 2679 A One-way Delay Metric for IPPM
5.34. RFC 2679 IPPM的单向延迟度量
This specification only supports IPv4.
此规范仅支持IPv4。
5.35. RFC 2680 A One-way Packet Loss Metric for IPPM
5.35. RFC 2680 IPPM的单向分组丢失度量
This specification only supports IPv4.
此规范仅支持IPv4。
5.36. RFC 2681 A Round-trip Delay Metric for IPPM
5.36. RFC 2681 IPPM的往返延迟度量
This specification only supports IPv4.
此规范仅支持IPv4。
5.37. RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP)
5.37. RFC2730多播地址动态客户端分配协议（MADCAP）
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.38. RFC 2733 An RTP Payload Format for Generic Forward Error Correction
5.38. RFC 2733通用前向纠错的RTP有效负载格式
This specification is dependent on SDP which has IPv4 dependencies. Once that limitation is fixed, then this specification should support IPv6.
此规范依赖于具有IPv4依赖关系的SDP。一旦这个限制被修复，那么这个规范应该支持IPv6。
5.39. RFC 2745 RSVP Diagnostic Messages
5.39. RFC 2745 RSVP诊断消息
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.40. RFC 2746 RSVP Operation Over IP Tunnels
5.40. RFC 2746 IP隧道上的RSVP操作
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.41. RFC 2750 RSVP Extensions for Policy Control
5.41. 用于策略控制的RFC 2750 RSVP扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.42. RFC 2793 RTP Payload for Text Conversation
5.42. 用于文本对话的RFC 2793 RTP有效负载
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.43. RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
5.43. RFC 2814 SBM（子网带宽管理器）：IEEE 802风格网络上基于RSVP的准入控制协议
This specification claims to be both IPv4 and IPv6 aware, but all of the examples are given with IPv4 addresses. That, by itself is not a telling point but the following statement is made:
该规范声称同时支持IPv4和IPv6，但所有示例都提供了IPv4地址。这本身并不是一个说明问题的要点，但有以下陈述：
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 0.0.0.0) and priority. All IP addresses are assumed to be in network byte order. In addition, current DSBM's L2 address is also stored as part of this state information.
a) LocalDSBMAddrInfo—当前DSBM的IP地址（最初为0.0.0.0）和优先级。假设所有IP地址都是按网络字节顺序排列的。此外，当前DSBM的L2地址也存储为该状态信息的一部分。
which could just be sloppy wording. Perhaps a short document clarifying the text is appropriate.
这可能只是草率的措辞。也许一份简短的文件澄清文本是合适的。
5.44. RFC 2815 Integrated Service Mappings on IEEE 802 Networks
5.44. IEEE 802网络上的RFC 2815集成服务映射
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.45. RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
5.45. 用于DTMF数字、电话音和电话信号的RFC 2833 RTP有效负载
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.46. RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
5.46. RFC 2848 PINT服务协议：SIP和SDP的扩展，用于电话呼叫服务的IP访问
This specification is dependent on SDP which has IPv4 dependencies. Once these limitations are fixed, then this specification should support IPv6.
此规范依赖于具有IPv4依赖关系的SDP。一旦这些限制被修复，那么这个规范应该支持IPv6。
5.47. RFC 2862 RTP Payload Format for Real-Time Pointers
5.47. RFC 2862实时指针的RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.48. RFC 2872 Application and Sub Application Identity Policy Element for Use with RSVP
5.48. RFC 2872用于RSVP的应用程序和子应用程序标识策略元素
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.49. RFC 2873 TCP Processing of the IPv4 Precedence Field
5.49. RFC 2873 IPv4优先字段的TCP处理
This specification documents a technique using IPv4 headers. A similar technique, if needed, will need to be defined for IPv6.
本规范记录了一种使用IPv4报头的技术。如果需要，需要为IPv6定义类似的技术。
5.50. RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP
5.50. RFC 2883 TCP选择性确认（SACK）选项的扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.51. RFC 2907 MADCAP Multicast Scope Nesting State Option
5.51. RFC 2907 MADCAP多播作用域嵌套状态选项
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.52. RFC 2960 Stream Control Transmission Protocol
5.52. RFC2960流控制传输协议
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.53. RFC 2961 RSVP Refresh Overhead Reduction Extensions
5.53. RFC 2961 RSVP刷新开销减少扩展
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.54. RFC 2976 The SIP INFO Method
5.54. RFC 2976 SIP INFO方法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.55. RFC 2988 Computing TCP's Retransmission Timer
5.55. RFC 2988计算TCP的重传计时器
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.56. RFC 2996 Format of the RSVP DCLASS Object
5.56. RSVP DCLASS对象的RFC 2996格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.57. RFC 2997 Specification of the Null Service Type
5.57. 空服务类型的RFC 2997规范
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.58. RFC 3003 The audio/mpeg Media Type
5.58. RFC 3003音频/mpeg媒体类型
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.59. RFC 3006 Integrated Services in the Presence of Compressible Flows
5.59. 存在可压缩流时的RFC 3006综合服务
This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined.
本文档定义了一个协议，该协议讨论可压缩流，但仅在IPv4上下文中讨论。定义IPv6可压缩流时，还应定义类似的技术。
5.60. RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams
5.60. 用于MPEG-4音频/视频流的RFC 3016 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.61. RFC 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol
5.61. RFC 3033互联网协议的Q.2941通用标识符和Q.2957用户对用户信令中信息字段和协议标识符的分配
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.62. RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit
5.62. RFC3042使用有限传输增强TCP的丢失恢复
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.63. RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1
5.63. ITU-T建议G.722.1的RFC 3047 RTP有效载荷格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.64. RFC 3057 ISDN Q.921-User Adaptation Layer
5.64. RFC 3057 ISDN Q.921-用户适配层
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.65. RFC 3095 Robust Header Compression (ROHC): Framework and four profiles
5.65. RFC3095鲁棒头压缩（ROHC）：框架和四个配置文件
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.66. RFC 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections
5.66. RFC 3108 ATM承载连接使用会话描述协议（SDP）的约定
This specification is currently limited to IPv4 as amplified below:
本规范目前仅限于IPv4，如下所述：
The range and format of the <rtcpPortNum> and <rtcpIPaddr> subparameters is per [1]. The <rtcpPortNum> is a decimal number between 1024 and 65535. It is an odd number. If an even number in this range is specified, the next odd number is used. The <rtcpIPaddr> is expressed in the usual dotted decimal IP address representation, from 0.0.0.0 to 255.255.255.255.
<rtcpPortNum>和<rtcpIPaddr>子参数的范围和格式符合[1]。<rtcpPortNum>是介于1024和65535之间的十进制数。这是一个奇数。如果指定此范围内的偶数，则使用下一个奇数。<rtcpIPaddr>以通常的点十进制IP地址表示形式表示，从0.0.0.0到255.255.255.255。
and
和
<rtcpIPaddr> IP address for receipt Dotted decimal, 7-15 chars of RTCP packets
<rtcpIPaddr>接收点十进制数据包的IP地址，7-15个字符的RTCP数据包
5.67. RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio
5.67. RFC 3119一种更耐丢失的RTP有效负载格式，适用于MP3音频
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.68. RFC 3124 The Congestion Manager
5.68. RFC 3124拥塞管理器
This document is IPv4 limited since it uses the IPv4 TOS header field.
此文档受IPv4限制，因为它使用IPv4 TOS标头字段。
5.69. RFC 3140 Per Hop Behavior Identification Codes
5.69. RFC 3140每跳行为识别码
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.70. RFC 3173 IP Payload Compression Protocol (IPComp)
5.70. RFC 3173 IP有效负载压缩协议（IPComp）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.71. RFC 3181 Signaled Preemption Priority Policy Element
5.71. RFC 3181信号抢占优先级策略元素
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.72. RFC 3182 Identity Representation for RSVP
5.72. RFC 3182 RSVP的标识表示
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.73. RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior)
5.73. RFC 3246加速转发PHB（每跳行为）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.74. RFC 3261 SIP: Session Initiation Protocol
5.74. RFC 3261 SIP：会话启动协议
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.75. RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP)
5.75. RFC 3262会话启动协议（SIP）中临时响应的可靠性
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.76. RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
5.76. RFC 3263会话启动协议（SIP）：定位SIP服务器
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.77. RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP)
5.77. RFC 3264带有会话描述协议（SDP）的提供/应答模型
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.78. RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification
5.78. RFC 3265会话启动协议（SIP）-特定事件通知
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.79. RFC 3390 Increasing TCP's Initial Window
5.79. RFC 3390增加TCP的初始窗口
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.80. RFC 3525 Gateway Control Protocol Version 1
5.80. RFC 3525网关控制协议版本1
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.81. RFC 3544 IP Header Compression over PPP
5.81. 基于PPP的RFC 3544 IP报头压缩
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Experimental RFCs typically define protocols that do not have widescale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases they are presented as alternatives to the mainstream solution to an acknowledged problem.
实验性RFC通常定义在Internet上没有大规模实现或使用的协议。它们通常在性质上是恰当的，或者在有限的领域中使用。为了允许潜在的互操作性或其他一些潜在的有用场景，它们被记录到互联网社区中。在少数情况下，它们被作为主流解决方案的替代方案来解决一个公认的问题。
6.1. RFC 908 Reliable Data Protocol (RDP)
6.1. RFC 908可靠数据协议（RDP）
This document is IPv4 limited as stated in the following section:
本文件受IPv4限制，如下节所述：
4.1. IP Header Format
4.1. IP头格式
When used in the internet environment, RDP segments are sent using the version 4 IP header as described in RFC791, "Internet Protocol." The RDP protocol number is ??? (decimal). The time-to-live field should be set to a reasonable value for the network.
在internet环境中使用时，RDP段使用RFC791“internet协议”中所述的版本4 IP头发送。RDP协议编号为？？？（十进制）。“生存时间”字段应设置为网络的合理值。
All other fields should be set as specified in RFC-791.
所有其他字段应按照RFC-791中的规定进行设置。
A new protocol specification would be needed to support IPv6.
需要新的协议规范来支持IPv6。
6.02. RFC 938 Internet Reliable Transaction Protocol functional and interface specification (IRTP)
6.02. RFC 938互联网可靠交易协议功能和接口规范（IRTP）
This specification states:
本规范规定：
4.1. State Variables
4.1. 状态变量
Each IRTP is associated with a single internet address. The synchronization mechanism of the IRTP depends on the requirement that each IRTP module knows the internet addresses of all modules with which it will communicate. For each remote internet address, an IRTP module must maintain the following information (called the connection table):
每个IRTP都与一个internet地址相关联。IRTP的同步机制取决于每个IRTP模块知道其将与之通信的所有模块的internet地址的要求。对于每个远程internet地址，IRTP模块必须维护以下信息（称为连接表）：
rem_addr (32 bit remote internet address)
rem_addr（32位远程互联网地址）
A new specification that is IPv6 aware would need to be created.
需要创建一个支持IPv6的新规范。
6.03. RFC 998 NETBLT: A bulk data transfer protocol
6.03. RFC 998 NETBLT：一种批量数据传输协议
This RFC states:
本RFC规定：
The active end specifies a passive client through a client-specific "well-known" 16 bit port number on which the passive end listens. The active end identifies itself through a 32 bit Internet address and a unique 16 bit port number.
主动端通过被动端侦听的特定于客户端的“已知”16位端口号指定被动客户端。活动端通过32位互联网地址和唯一的16位端口号来识别自身。
Clearly, this is IPv4 dependent, but could easily be modified to support IPv6 addressing.
显然，这依赖于IPv4，但可以轻松修改以支持IPv6寻址。
6.04. RFC 1045 VMTP: Versatile Message Transaction Protocol
6.04. RFC 1045 VMTP：通用消息事务协议
This specification has many IPv4 dependencies in its implementation appendices. For operations over IPv6 a similar implementation procedure must be defined. The IPv4 specific information is show below.
该规范在其实现附录中有许多IPv4依赖项。对于IPv6上的操作，必须定义类似的实施过程。IPv4特定信息如下所示。
IV.1. Domain 1
四、 一,。域1
For initial use of VMTP, we define the domain with Domain identifier 1 as follows:
对于VMTP的初始使用，我们将域标识符为1的域定义如下：
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Address |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Address |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
The Internet address is the Internet address of the host on which this entity-id is originally allocated. The Discriminator is an arbitrary value that is unique relative to this Internet host address. In addition, the host must guarantee that this identifier does not get reused for a long period of time after it becomes invalid. ("Invalid" means that no VMTP module considers in bound to an entity.) One technique is to use the lower order bits of a 1 second clock. The clock need not represent real-time but must never be set back after a crash. In a simple implementation, using the low order bits of a clock as the time stamp, the generation of unique identifiers is overall limited to no more than 1 per second on average. The type flags were described in Section 3.1.
Internet地址是最初分配此实体id的主机的Internet地址。鉴别器是相对于此Internet主机地址唯一的任意值。此外，主机必须保证该标识符在失效后很长一段时间内不会被重用。（“无效”表示VMTP模块不考虑绑定到实体。）一种技术是使用1秒时钟的低阶位。时钟不需要代表实时，但在崩溃后决不能后退。在一个简单的实现中，使用时钟的低阶位作为时间戳，唯一标识符的生成总体上被限制为平均不超过每秒1个。第3.1节描述了类型标志。
An entity may migrate between hosts. Thus, an implementation can heuristically use the embedded Internet address to locate an entity but should be prepared to maintain a cache of redirects for migrated entities, plus accept Notify operations indicating that migration has occurred.
实体可以在主机之间迁移。因此，实现可以试探性地使用嵌入的因特网地址来定位实体，但应该准备好为迁移的实体维护重定向缓存，以及接受指示迁移已经发生的通知操作。
Entity group identifiers in Domain 1 are structured in one of two forms, depending on whether they are well-known or dynamically allocated identifiers. A well-known entity identifier is structured as:
域1中的实体组标识符采用两种形式中的一种，这取决于它们是众所周知的标识符还是动态分配的标识符。众所周知的实体标识符的结构如下：
+-----------+----------------+------------------------+
| TypeFlags | Discriminator |Internet Host Group Addr|
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+
| TypeFlags | Discriminator |Internet Host Group Addr|
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
with the second high-order bit (GRP) set to 1. This form of entity identifier is mapped to the Internet host group address specified in the low-order 32 bits. The Discriminator distinguishes group identifiers using the same Internet host group. Well-known entity group identifiers should be allocated to correspond to the basic services provided by hosts that are members of the group, not specifically because that service is provided by VMTP. For example, the well-known entity group identifier for the domain name service should contain as its embedded Internet host group address the host group for Domain Name servers.
将第二高位（GRP）设置为1。这种形式的实体标识符映射到低阶32位中指定的Internet主机组地址。鉴别器使用相同的因特网主机组来区分组标识符。应该分配众所周知的实体组标识符，以与作为组成员的主机提供的基本服务相对应，这并不是因为该服务是由VMTP提供的。例如，域名服务的知名实体组标识符应包含域名服务器的主机组作为其嵌入式Internet主机组地址。
A dynamically allocated entity identifier is structured as:
动态分配的实体标识符的结构如下：
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Host Addr |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Host Addr |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
with the second high-order bit (GRP) set to 1. The Internet address in the low-order 32 bits is a Internet address assigned to the host that dynamically allocates this entity group identifier. A dynamically allocated entity group identifier is mapped to Internet host group address 232.X.X.X where X.X.X are the low-order 24 bits of the Discriminator subfield of the entity group identifier.
将第二高位（GRP）设置为1。低位32位的Internet地址是分配给动态分配此实体组标识符的主机的Internet地址。动态分配的实体组标识符映射到Internet主机组地址232.X.X.X，其中X.X.X是实体组标识符的鉴别器子字段的低位24位。
We use the following notation for Domain 1 entity identifiers <10> and propose it use as a standard convention.
我们对域1实体标识符<10>使用以下符号，并建议将其用作标准约定。
<flags>-<discriminator>-<Internet address>
<flags>-<discriminator>-<Internet address>
where <flags> are [X]{BE,LE,RG,UG}[A]
where <flags> are [X]{BE,LE,RG,UG}[A]
X = reserved BE = big-endian entity LE = little-endian entity RG = restricted group UG = unrestricted group A = alias
X=保留BE=大端实体LE=小端实体RG=受限组UG=非受限组A=别名
and <discriminator> is a decimal integer and <Internet address> is in standard dotted decimal IP address notation.
<discriminator>是一个十进制整数，<internetaddress>是标准的点十进制IP地址表示法。
V.1. Authentication Domain 1
V.1. 身份验证域1
A principal identifier is structured as follows.
主体标识符的结构如下所示。
+---------------------------+------------------------+
| Internet Address | Local User Identifier |
+---------------------------+------------------------+
32 bits 32 bits
+---------------------------+------------------------+
| Internet Address | Local User Identifier |
+---------------------------+------------------------+
32 bits 32 bits
VI. IP Implementation
六、 IP实现
VMTP is designed to be implemented on the DoD IP Internet Datagram Protocol (although it may also be implemented as a local network protocol directly in "raw" network packets.)
VMTP设计用于在国防部IP互联网数据报协议上实施（尽管它也可以直接在“原始”网络数据包中作为本地网络协议实施。）
The well-known entity identifiers specified to date are:
迄今为止指定的众所周知的实体标识符为：
VMTP_MANAGER_GROUP RG-1-224.0.1.0 Managers for VMTP operations.
VMTP_经理团队RG-1-224.0.1.0 VMTP运营经理。
VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0 Client entity identifier to use when a (big-endian) host has not determined or been allocated any client entity identifiers.
VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0当（big-endian）主机尚未确定或分配任何客户端实体标识符时使用的客户端实体标识符。
VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0 Client entity identifier to use when a (little-endian) host has not determined or been allocated any client entity identifiers.
VMTP_默认_LECLIENT LE-1-224.0.1.0当（小端）主机尚未确定或分配任何客户端实体标识符时使用的客户端实体标识符。
Note that 224.0.1.0 is the host group address assigned to VMTP and to which all VMTP hosts belong.
请注意，224.0.1.0是分配给VMTP的主机组地址，所有VMTP主机都属于该地址。
6.05. RFC 1146 TCP alternate checksum options
6.05. RFC 1146 TCP备用校验和选项
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.06. RFC 1151 Version 2 of the Reliable Data Protocol (RDP)
6.06. RFC 1151可靠数据协议（RDP）第2版
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.07. RFC 1644 T/TCP -- TCP Extensions for Transactions Functional Specification
6.07. RFC1644T/TCP——事务的TCP扩展功能规范
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.08. RFC 1693 An Extension to TCP : Partial Order Service
6.08. RFC1693对TCP:部分订购服务的扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.09. RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU
6.09. 带有固定路径MTU的IPX网络上的RFC 1791 TCP和UDP
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.10. RFC 2343 RTP Payload Format for Bundled MPEG
6.10. 用于捆绑MPEG的RFC 2343 RTP有效负载格式
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.11. RFC 2582 The NewReno Modification to TCP's Fast Recovery Algorithm
6.11. RFC 2582对TCP快速恢复算法的NewReno修改
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.12. RFC 2762 Sampling of the Group Membership in RTP
6.12. RFC 2762 RTP中的组成员资格抽样
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.13. RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM)
6.13. RFC 2859 A时间滑动窗口三色标记（TSWTCM）
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
6.14. RFC 2861 TCP Congestion Window Validation
6.14. RFC 2861 TCP拥塞窗口验证
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
6.15. RFC 2909 The Multicast Address-Set Claim (MASC) Protocol
6.15. RFC 2909多播地址集声明（MASC）协议
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
In the initial survey of RFCs 24 positives were identified out of a total of 104, broken down as follows:
在对RFC的初步调查中，从总共104个样本中确定了24个阳性样本，细分如下：
Standards: 3 out of 5 or 60.00% Draft Standards: 0 out of 2 or 0.00% Proposed Standards: 17 out of 82 or 20.73% Experimental RFCs: 4 out of 15 or 26.67%
标准：5分之3或60.00%标准草案：2分之0或0.00%建议标准：82分之17或20.73%实验性RFC：15分之4或26.67%
Of those identified many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that SHOULD be updated but do not cause any operational impact if they are not updated. The remaining instances are documented below.
在已确定的协议中，许多协议不需要采取行动，因为它们记录了过时和未使用的协议，而其他协议则记录了相关工作组正在积极更新的协议。此外，还有许多应更新的标准实例，但如果不更新，则不会造成任何运营影响。其余实例记录如下。
7.1.1. STD 7 Transmission Control Protocol (RFC 793)
7.1.1. STD 7传输控制协议（RFC 793）
Section 3.1 defines the technique for computing the TCP checksum that uses the 32 bit source and destination IPv4 addresses. This problem is addressed in RFC 2460 Section 8.1.
第3.1节定义了使用32位源和目标IPv4地址计算TCP校验和的技术。RFC 2460第8.1节对该问题进行了说明。
7.1.2. STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002)
7.1.2. TCP/UDP上的STD 19 Netbios（RFCs 1001和1002）
These two RFCs have many inherent IPv4 assumptions and a new set of protocols must be defined.
这两个RFC有许多固有的IPv4假设，必须定义一组新的协议。
7.1.3. STD 35 ISO Transport over TCP (RFC 1006)
7.1.3. STD 35 TCP上的ISO传输（RFC 1006）
This problem has been fixed in RFC 2126, ISO Transport Service on top of TCP.
这个问题已经在RFC2126中修复，它是TCP之上的ISO传输服务。
There are no draft standards within the scope of this document.
本文件范围内没有标准草案。
7.3.01. TCP/IP Header Compression over Slow Serial Links (RFC 1144)
7.3.01. 慢速串行链路上的TCP/IP报头压缩（RFC 1144）
This problem has been resolved in RFC2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509.
这个问题在RFC2508中得到了解决，它为低速串行链路压缩IP/UDP/RTP报头。另见RFC 2507和RFC 2509。
7.3.02. ONC RPC v2 (RFC 1833)
7.3.02. ONC RPC v2（RFC 1833）
The problems can be resolved with a definition of the NC_INET6 protocol family.
这些问题可以通过定义NC_INET6协议系列来解决。
7.3.03. RTSP (RFC 2326)
7.3.03. RTSP（RFC2326）
Problem has been acknowledged by the RTSP developer group and will be addressed in the move from Proposed to Draft Standard. This problem is also addressed in RFC 2732, IPv6 Literal Addresses in URL's.
RTSP开发小组已经认识到这个问题，并将在从建议标准到起草标准的过程中加以解决。RFC2732，URL中的IPv6文本地址也解决了这个问题。
7.3.04. SDP (RFC 2327)
7.3.04. SDP（RFC2327）
One problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. The other problem can be addressed with a minor textual clarification. This must be done if the document is to transition from Proposed to Draft. These problems are solved by documents currently in Auth48 or IESG discuss.
RFC2732中解决了一个问题，即URL中的IPv6文本地址。另一个问题可以通过一个小的文本澄清来解决。如果文件要从提议的过渡到草案，必须这样做。这些问题通过Auth48或IESG讨论中的现有文件得到解决。
7.3.05. IPPM Metrics (RFC 2678)
7.3.05. IPPM指标（RFC 2678）
The IPPM WG is working to resolve these issues.
IPPM工作组正在努力解决这些问题。
7.3.06. IPPM One Way Delay Metric for IPPM (RFC 2679)
7.3.06. IPPM的单向延迟度量（RFC 2679）
The IPPM WG is working to resolve these issues. An ID is available (draft-ietf-ippm-owdp-03.txt).
IPPM工作组正在努力解决这些问题。ID可用（draft-ietf-ippm-owdp-03.txt）。
7.3.07. IPPM One Way Packet Loss Metric for IPPM (RFC 2680)
7.3.07. IPPM的单向分组丢失度量（RFC 2680）
The IPPM WG is working to resolve these issues.
IPPM工作组正在努力解决这些问题。
7.3.09. Round Trip Delay Metric for IPPM (RFC 2681)
7.3.09. IPPM的往返延迟度量（RFC 2681）
The IPPM WG is working to resolve these issues.
IPPM工作组正在努力解决这些问题。
7.3.08. The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services(RFC 2848)
7.3.08. PINT服务协议：SIP和SDP的扩展，用于电话呼叫服务的IP访问（RFC 2848）
This specification is dependent on SDP which has IPv4 dependencies. Once these limitations are fixed, then this protocol should support IPv6.
此规范依赖于具有IPv4依赖关系的SDP。一旦这些限制被修复，那么这个协议应该支持IPv6。
7.3.09. TCP Processing of the IPv4 Precedence Field (RFC 2873)
7.3.09. IPv4优先字段的TCP处理（RFC 2873）
The problems are not being addressed.
这些问题没有得到解决。
7.3.10. Integrated Services in the Presence of Compressible Flows (RFC 3006)
7.3.10. 存在可压缩流时的综合服务（RFC 3006）
This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined.
本文档定义了一个协议，该协议讨论可压缩流，但仅在IPv4上下文中讨论。定义IPv6可压缩流时，还应定义类似的技术。
7.3.11. SDP For ATM Bearer Connections (RFC 3108)
7.3.11. ATM承载连接的SDP（RFC 3108）
The problems are not being addressed, but it is unclear whether the specification is being used.
这些问题尚未得到解决，但尚不清楚是否正在使用该规范。
7.3.12. The Congestion Manager (RFC 3124)
7.3.12. 拥塞管理器（RFC3124）
An update to this document can be simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field.
对本文档的更新可以简单地定义IPv6流量类字段的使用，因为它的定义与IPv4 TOS字段完全相同。
7.4.1. Reliable Data Protocol (RFC 908)
7.4.1. 可靠数据协议（RFC 908）
This specification relies on IPv4 and a new protocol standard may be produced.
该规范依赖于IPv4，可能会产生新的协议标准。
7.4.2. Internet Reliable Transaction Protocol functional and interface specification (RFC 938)
7.4.2. 互联网可靠交易协议功能和接口规范（RFC 938）
This specification relies on IPv4 and a new protocol standard may be produced.
该规范依赖于IPv4，可能会产生新的协议标准。
7.4.3. NETBLT: A bulk data transfer protocol (RFC 998)
7.4.3. NETBLT：大容量数据传输协议（RFC 998）
This specification relies on IPv4 and a new protocol standard may be produced.
该规范依赖于IPv4，可能会产生新的协议标准。
7.4.4. VMTP: Versatile Message Transaction Protocol (RFC 1045)
7.4.4. VMTP：通用消息事务协议（RFC 1045）
This specification relies on IPv4 and a new protocol standard may be produced.
该规范依赖于IPv4，可能会产生新的协议标准。
7.4.5. OSPF over ATM and Proxy-PAR (RFC 2844)
7.4.5. ATM上的OSPF和代理PAR（RFC 2844）
This specification relies on IPv4 and a new protocol standard may be produced.
该规范依赖于IPv4，可能会产生新的协议标准。
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
本备忘录审查了规范的IPv6准备情况；这本身没有安全考虑。
The authors would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally the author, Philip J. Nesser II, would like to thanks his partner in all ways, Wendy M. Nesser.
作者希望感谢互联网协会在本文件的研究和制作过程中提供的支持。此外，作者Philip J.Nesser II想感谢他的合作伙伴Wendy M.Nesser。
The editor, Andreas Bergstrom, would like to thank Pekka Savola for guidance and collection of comments for the editing of this document. He would further like to thank Allison Mankin, Magnus Westerlund and Colin Perkins for valuable feedback on some points of this document.
编辑Andreas Bergstrom感谢Pekka Savola为本文件的编辑提供指导和收集意见。他还要感谢Allison Mankin、Magnus Westerlund和Colin Perkins就本文件的一些要点提供了宝贵的反馈。
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards", RFC 3789, June 2004.
[1] Nesser，II，P.和A.Bergstrom，编辑，“当前部署的IETF标准中IPv4地址调查简介”，RFC 3789，2004年6月。
Please contact the authors with any questions, comments or suggestions at:
如有任何问题、意见或建议，请联系作者：
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
Philip J.Nesser II首席Nesser&Nesser Consulting 13501东北第100大道，华盛顿州柯克兰市5202号，邮编：98034
Phone: +1 425 481 4303
Fax: +1 425 48
EMail: phil@nesser.com
Phone: +1 425 481 4303
Fax: +1 425 48
EMail: phil@nesser.com
Andreas Bergstrom, Editor Ostfold University College Rute 503 Buer N-1766 Halden Norway
Andreas Bergstrom，编辑奥斯特福德大学学院Rute 503 Buer N-1766挪威哈尔登
EMail: andreas.bergstrom@hiof.no
EMail: andreas.bergstrom@hiof.no
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。