Network Working Group P. Nesser, II
Request for Comments: 3796 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Network Working Group P. Nesser, II
Request for Comments: 3796 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management 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 record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented.
本文档旨在记录当前部署的IETF操作和管理领域公认标准中IPv4地址的所有使用情况。为了成功地从全IPv4 Internet过渡到全IPv6 Internet，将采取许多临时步骤。其中一个步骤是发展具有IPv4依赖关系的当前协议。人们希望这些协议（及其实现）将被重新设计为与网络地址无关，但如果不能做到这一点，则至少会同时支持IPv4和IPv6。为此，将对所有标准（完整、草案和提议）以及实验性RFC进行调查，并记录任何依赖关系。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 9
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . . 36
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . . 36
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . . 37
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . . 40
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 40
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative Reference. . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . 41
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 43
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 9
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . . 36
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . . 36
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . . 37
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . . 40
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 40
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative Reference. . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . 41
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 43
This document is part of a set aiming to record 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 document is organized as 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.
完整的互联网标准（通常简称为“标准”）是在整个互联网上广泛实施和使用的完全成熟的协议规范。
Section 3.2.3.2. IpAddress defines the following:
第3.2.3.2节。IpAddress定义了以下内容：
This application-wide type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order.
此应用程序范围的类型表示32位internet地址。它表示为长度为4的八位字节字符串，按网络字节顺序排列。
There are several instances of the use of this definition in the rest of the document.
在本文档的其余部分中有几个使用此定义的实例。
In section 4.1.6 IpAddress is defined as:
在第4.1.6节中，IP地址定义为：
(6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d notation.
(6) IpAddress值：4个子标识符，采用熟悉的a.b.c.d符号。
There are far too many instances of IPv4 addresses is this document to enumerate here. The particular object groups that are affected are the IP group, the ICMP group, the TCP group, the UDP group, and the EGP group.
本文档中的IPv4地址实例太多，无法在此列举。受影响的特定对象组是IP组、ICMP组、TCP组、UDP组和EGP组。
Section 7.1.5 defines the IpAddress data type:
第7.1.5节定义了IpAddress数据类型：
The IpAddress type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order.
IpAddress类型表示32位internet地址。它表示为长度为4的八位字节字符串，按网络字节顺序排列。
Note that the IpAddress type is a tagged type for historical reasons. Network addresses should be represented using an invocation of the TEXTUAL-CONVENTION macro.
请注意，出于历史原因，IpAddress类型是标记类型。网络地址应该使用文本约定宏的调用来表示。
Note the deprecated status of this type; see RFC 3291 for details on the replacement TEXTUAL-CONVENTION definitions.
请注意此类型的已弃用状态；有关替换文本约定定义的详细信息，请参见RFC 3291。
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依赖项。
3.9. RFC 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
3.9. RFC 3412简单网络管理协议（SNMP）的消息处理和调度
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
3.11. RFC 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
3.11. 简单网络管理协议（SNMPv3）版本3的RFC 3414基于用户的安全模型（USM）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
3.12. RFC 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
3.12. 用于简单网络管理协议（SNMP）的RFC 3415基于视图的访问控制模型（VACM）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
3.13. RFC 3416 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMP)
3.13. 简单网络管理协议（SNMP）版本2的RFC 3416协议操作
Section 4.2.2.1., Example of Table Traversal, and Section 4.2.3.1., Another Example of Table Traversal, both use objects from MIB2 whose data contains IPv4 addresses. Other than their use in these example sections, there are no IPv4 dependencies in this specification.
第4.2.2.1节“表遍历示例”和第4.2.3.1节“表遍历另一示例”都使用MIB2中的对象，其数据包含IPv4地址。除了在这些示例部分中使用之外，本规范中没有IPv4依赖项。
3.14. RFC 3417 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMP)
3.14. 简单网络管理协议（SNMP）版本2的RFC 3417传输映射
Section 2 Definitions contains the following definition:
第2节定义包含以下定义：
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP address:
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP address:
octets contents encoding 1-4 IP-address network-byte order 5-6 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (6))
八位字节内容编码1-4 IP地址网络字节顺序5-6 UDP端口网络字节顺序“语法八位字节字符串（大小（6））
Section 8.1, Usage Example, also contains examples which uses IPv4 address, but it has no significance in the operation of the specification.
第8.1节“使用示例”也包含使用IPv4地址的示例，但在规范的操作中没有意义。
3.15. RFC 3418 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMP)
3.15. 简单网络管理协议（SNMP）版本2的RFC 3418管理信息库
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
标准草案代表IETF中倒数第二个标准级别。只有当存在多个独立的、可互操作的实现时，协议才能实现标准草案。标准草案通常是相当成熟和广泛使用的。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.3. RFC 1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2
4.3. RFC 1657使用SMIv2的第四版边界网关协议（BGP-4）的托管对象定义
The MIB defined in this RFC deals with objects in a BGP4 based routing system and therefore contain many objects that are limited by the IpAddress 32-bit value defined in MIB2. Clearly the values of this MIB are limited to IPv4 addresses. No update is needed, although a new MIB should be defined for BGP4+ to allow management of IPv6 addresses and routes.
此RFC中定义的MIB处理基于BGP4的路由系统中的对象，因此包含许多受MIB2中定义的IpAddress 32位值限制的对象。显然，此MIB的值仅限于IPv4地址。无需更新，但应为BGP4+定义新的MIB以允许管理IPv6地址和路由。
4.4. RFC 1658 Definitions of Managed Objects for Character Stream Devices using SMIv2
4.4. RFC 1658使用SMIv2的字符流设备的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.5. RFC 1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2
4.5. RFC 1659使用SMIv2的RS-232类硬件设备的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.6. RFC 1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2
4.6. RFC 1660使用SMIv2的并行打印机类硬件设备的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.7. RFC 1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2
4.7. RFC 1694使用SMIv2的SMDS接口的托管对象定义
This MIB module definition defines the following subtree:
此MIB模块定义定义了以下子树：
ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 }
ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 }
-- Although the objects in this group are read-only, at the
-- agent's discretion they may be made read-write so that the
-- management station, when appropriately authorized, may
-- change the addressing information related to the
-- configuration of a logical IP subnetwork implemented on
-- top of SMDS.
-- Although the objects in this group are read-only, at the
-- agent's discretion they may be made read-write so that the
-- management station, when appropriately authorized, may
-- change the addressing information related to the
-- configuration of a logical IP subnetwork implemented on
-- top of SMDS.
-- This table is necessary to support RFC1209 (IP-over-SMDS)
-- and gives information on the Group Addresses and ARP
-- Addresses used in the Logical IP subnetwork.
-- One SMDS address may be associated with multiple IP
-- addresses. One SNI may be associated with multiple LISs.
-- This table is necessary to support RFC1209 (IP-over-SMDS)
-- and gives information on the Group Addresses and ARP
-- Addresses used in the Logical IP subnetwork.
-- One SMDS address may be associated with multiple IP
-- addresses. One SNI may be associated with multiple LISs.
ipOverSMDSTable OBJECT-TYPE SYNTAX SEQUENCE OF IpOverSMDSEntry MAX-ACCESS not-accessible
IpOverSMDSEntry MAX-ACCESS的ipOverSMDSTable对象类型语法序列不可访问
STATUS current
DESCRIPTION
"The table of addressing information relevant to
this entity's IP addresses."
::= { ipOverSMDS 1 }
STATUS current
DESCRIPTION
"The table of addressing information relevant to
this entity's IP addresses."
::= { ipOverSMDS 1 }
ipOverSMDSEntry OBJECT-TYPE
SYNTAX IpOverSMDSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The addressing information for one of this
entity's IP addresses."
INDEX { ipOverSMDSIndex, ipOverSMDSAddress }
::= { ipOverSMDSTable 1 }
ipOverSMDSEntry OBJECT-TYPE
SYNTAX IpOverSMDSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The addressing information for one of this
entity's IP addresses."
INDEX { ipOverSMDSIndex, ipOverSMDSAddress }
::= { ipOverSMDSTable 1 }
IpOverSMDSEntry ::=
SEQUENCE {
ipOverSMDSIndex IfIndex,
ipOverSMDSAddress IpAddress,
ipOverSMDSHA SMDSAddress,
ipOverSMDSLISGA SMDSAddress,
ipOverSMDSARPReq SMDSAddress
}
IpOverSMDSEntry ::=
SEQUENCE {
ipOverSMDSIndex IfIndex,
ipOverSMDSAddress IpAddress,
ipOverSMDSHA SMDSAddress,
ipOverSMDSLISGA SMDSAddress,
ipOverSMDSARPReq SMDSAddress
}
ipOverSMDSIndex OBJECT-TYPE
SYNTAX IfIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object identifies the
interface for which this entry contains management
information. "
::= { ipOverSMDSEntry 1 }
ipOverSMDSIndex OBJECT-TYPE
SYNTAX IfIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object identifies the
interface for which this entry contains management
information. "
::= { ipOverSMDSEntry 1 }
ipOverSMDSAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address to which this entry's addressing
information pertains."
::= { ipOverSMDSEntry 2 }
ipOverSMDSAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address to which this entry's addressing
information pertains."
::= { ipOverSMDSEntry 2 }
ipOverSMDSHA OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current
ipOverSMDSHA对象类型语法SMDSAddress MAX-ACCESS只读状态当前
DESCRIPTION
"The SMDS Individual address of the IP station."
::= { ipOverSMDSEntry 3 }
DESCRIPTION
"The SMDS Individual address of the IP station."
::= { ipOverSMDSEntry 3 }
ipOverSMDSLISGA OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS Group Address that has been configured
to identify the SMDS Subscriber-Network Interfaces
(SNIs) of all members of the Logical IP Subnetwork
(LIS) connected to the network supporting SMDS."
::= { ipOverSMDSEntry 4 }
ipOverSMDSLISGA OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS Group Address that has been configured
to identify the SMDS Subscriber-Network Interfaces
(SNIs) of all members of the Logical IP Subnetwork
(LIS) connected to the network supporting SMDS."
::= { ipOverSMDSEntry 4 }
ipOverSMDSARPReq OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS address (individual or group) to which
ARP Requests are to be sent."
::= { ipOverSMDSEntry 5 }
ipOverSMDSARPReq OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS address (individual or group) to which
ARP Requests are to be sent."
::= { ipOverSMDSEntry 5 }
Although these object definitions are intended for IPv4 addresses, a similar MIB can be defined for IPv6 addressing.
尽管这些对象定义用于IPv4地址，但也可以为IPv6地址定义类似的MIB。
As expected, this RFC is filled with IPv4 dependencies since it defines a MIB module for an IPv4-only routing protocol. A new MIB for RIPng is required.
正如所料，此RFC充满了IPv4依赖项，因为它为仅IPv4的路由协议定义了MIB模块。RIPng需要一个新的MIB。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This MIB defines managed objects for OSPFv2 which is a protocol used to exchange IPv4 routing information. Since OSPFv2 is limited to IPv4 addresses, a new MIB is required to support a new version of OSPF that is IPv6 aware.
此MIB为OSPFv2定义托管对象，OSPFv2是用于交换IPv4路由信息的协议。由于OSPFv2仅限于IPv4地址，因此需要新的MIB来支持支持支持IPv6的新版本OSPF。
4.11. RFC 2115 Management Information Base for Frame Relay DTEs Using SMIv2
4.11. 使用SMIv2的帧中继DTE的RFC 2115管理信息库
This specification has several examples of how IPv4 addresses might be mapped to Frame Relay DLCIs. Other than those examples there are no IPv4 dependencies in this specification.
本规范提供了几个示例，说明如何将IPv4地址映射到帧中继DLCI。除了这些示例之外，本规范中没有IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification. There is some discussion in one object definition about an interface performing a self test, but the object itself is IP version independent.
此规范中不存在IPv4依赖项。在一个对象定义中，对执行自检的接口进行了一些讨论，但对象本身与IP版本无关。
4.14. RFC 3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)
4.14. RFC 3592同步光网络/同步数字体系（SONET/SDH）受管对象的定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
4.15. RFC 3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
4.15. RFC 3593使用基于15分钟间隔的性能历史记录的MIB模块的文本约定
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标准过程中从未实施或推进提议的标准。因此，它们通常只是向互联网社区提出的想法。有时缺陷会暴露出来，或者是许多相互竞争的问题解决方案之一。在后一种情况下，不进行讨论，因为这不符合本次讨论的目的。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.2. RFC 1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3
5.2. RFC 1269边界网关协议的托管对象定义：版本3
The use of BGP3 has been deprecated and is not discussed.
BGP3的使用已被弃用，未进行讨论。
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.10. RFC 1461 SNMP MIB extension for Multiprotocol Interconnect over X.25
5.10. RFC 1461 SNMP MIB扩展，用于X.25上的多协议互连
The following objects are defined in Section 4, Definitions:
第4节“定义”中定义了以下对象：
mioxPleLastFailedEnAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2..128)) ACCESS read-only STATUS mandatory DESCRIPTION "The last Encapsulated address that failed to find a corresponding X.121 address and caused mioxPleEnAddrToX121LkupFlrs to be incremented. The first octet of this object contains the encapsulation type, the remaining octets contain the address of that type that failed. Thus for an IP address, the length will be five octets, the first octet will contain 204 (hex CC), and the last four octets will contain the IP
MIOxpleLastFailedEndAddr对象类型语法八位字节字符串（大小（2..128））访问只读状态强制说明“未能找到对应的X.121地址并导致mioxPleEnAddrToX121LkupFlrs递增的最后一个封装地址。此对象的第一个八位字节包含封装类型，其余八位字节包含失败类型的地址。因此，对于IP地址，长度将为五个八位字节，第一个八位字节将包含204（十六进制CC），最后四个八位字节将包含IP地址
address. For a snap encapsulation, the
first byte would be 128 (hex 80) and the
rest of the octet string would have the snap
header."
::= { mioxPleEntry 4 }
address. For a snap encapsulation, the
first byte would be 128 (hex 80) and the
rest of the octet string would have the snap
header."
::= { mioxPleEntry 4 }
mioxPeerEnAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..128)) ACCESS read-write STATUS mandatory DESCRIPTION "The Encapsulation address of the remote host mapped by this table entry. A length of zero indicates the remote IP address is unknown or unspecified for use as a PLE default.
mioxPeerEnAddr对象类型语法八位字节字符串（大小（0..128））访问读写状态强制说明“此表项映射的远程主机的封装地址。长度为零表示远程IP地址未知或未指定，无法用作PLE默认地址。
The first octet of this object contains the
encapsulation type, the remaining octets
contain an address of that type. Thus for
an IP address, the length will be five
octets, the first octet will contain 204
(hex CC), and the last four octets will
contain the IP address. For a snap
encapsulation, the first byte would be 128
(hex 80) and the rest of the octet string
would have the snap header."
DEFVAL { ''h }
::= { mioxPeerEntry 7 }
The first octet of this object contains the
encapsulation type, the remaining octets
contain an address of that type. Thus for
an IP address, the length will be five
octets, the first octet will contain 204
(hex CC), and the last four octets will
contain the IP address. For a snap
encapsulation, the first byte would be 128
(hex 80) and the rest of the octet string
would have the snap header."
DEFVAL { ''h }
::= { mioxPeerEntry 7 }
mioxPeerEncType OBJECT-TYPE SYNTAX INTEGER (0..256) ACCESS read-write STATUS mandatory DESCRIPTION "The value of the encapsulation type. For IP encapsulation this will have a value of 204 (hex CC). For SNAP encapsulated packets, this will have a value of 128 (hex 80). For CLNP, ISO 8473, this will have a value of 129 (hex 81). For ES-ES, ISO 9542, this will have a value of 130 (hex 82). A value of 197 (hex C5) identifies the Blacker X.25 encapsulation. A value of 0, identifies the Null encapsulation.
mioxPeerEncType对象类型语法整数（0..256）访问读写状态强制说明“封装类型的值。对于IP封装，此值为204（十六进制CC）。对于快照封装的数据包，此值为128（十六进制80）。对于CLNP，ISO 8473，此值为129（十六进制81）。对于ES-ES，ISO 9542，其值为130（十六进制82）。值为197（十六进制C5）表示更黑的X.25封装。值为0表示空封装。
This value can only be written when the mioxPeerStatus object with the same
只有当mioxPeerStatus对象具有相同的
mioxPeerIndex has a value of underCreation.
Setting this object to a value of 256
deletes the entry. When deleting an entry,
all other entries in the mioxPeerEncTable
with the same mioxPeerIndex and with an
mioxPeerEncIndex higher then the deleted
entry, will all have their mioxPeerEncIndex
values decremented by one."
::= { mioxPeerEncEntry 2 }
mioxPeerIndex has a value of underCreation.
Setting this object to a value of 256
deletes the entry. When deleting an entry,
all other entries in the mioxPeerEncTable
with the same mioxPeerIndex and with an
mioxPeerEncIndex higher then the deleted
entry, will all have their mioxPeerEncIndex
values decremented by one."
::= { mioxPeerEncEntry 2 }
Updated values of the first byte of these objects can be defined to support IPv6 addresses.
可以定义这些对象的第一个字节的更新值以支持IPv6地址。
5.11. RFC 1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol
5.11. RFC 1471点到点协议链路控制协议的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.12. RFC 1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol
5.12. RFC 1472点到点协议安全协议的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.13. RFC 1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol
5.13. RFC 1473点到点协议的IP网络控制协议的托管对象定义
This MIB module is targeted specifically at IPv4 over PPP. A new MIB module would need to be defined to support IPv6 over PPP.
此MIB模块专门针对IPv4 over PPP。需要定义一个新的MIB模块来支持PPP上的IPv6。
5.14. RFC 1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol
5.14. RFC 1474点到点协议网桥网络控制协议的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.16. RFC 1513 Token Ring Extensions to the Remote Network Monitoring MIB
5.16. 远程网络监控MIB的RFC 1513令牌环扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.17. RFC 1525 Definitions of Managed Objects for Source Routing Bridges
5.17. RFC 1525源路由桥的托管对象定义
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 1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2
5.21. RFC1697使用SMIv2的关系数据库管理系统（RDBMS）管理信息库（MIB）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
The following objects are defined:
定义了以下对象：
KipEntry ::= SEQUENCE {
kipNetStart ATNetworkNumber,
kipNetEnd ATNetworkNumber,
kipNextHop IpAddress,
kipHopCount INTEGER,
kipBCastAddr IpAddress,
kipCore INTEGER,
kipType INTEGER,
kipState INTEGER,
kipShare INTEGER,
kipFrom IpAddress
}
KipEntry ::= SEQUENCE {
kipNetStart ATNetworkNumber,
kipNetEnd ATNetworkNumber,
kipNextHop IpAddress,
kipHopCount INTEGER,
kipBCastAddr IpAddress,
kipCore INTEGER,
kipType INTEGER,
kipState INTEGER,
kipShare INTEGER,
kipFrom IpAddress
}
kipNextHop OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The IP address of the next hop in the route to this
entry's destination network."
::= { kipEntry 3 }
kipNextHop OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The IP address of the next hop in the route to this
entry's destination network."
::= { kipEntry 3 }
kipBCastAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION
kipBCastAddr对象类型语法IpAddress访问读写状态强制说明
"The form of the IP address used to broadcast on this
network."
::= { kipEntry 5 }
"The form of the IP address used to broadcast on this
network."
::= { kipEntry 5 }
kipFrom OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The IP address from which the routing entry was
learned via the AA protocol. If this entry was not
created via the AA protocol, it should contain IP
address 0.0.0.0."
::= { kipEntry 10 }
kipFrom OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The IP address from which the routing entry was
learned via the AA protocol. If this entry was not
created via the AA protocol, it should contain IP
address 0.0.0.0."
::= { kipEntry 10 }
5.23. RFC 1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2
5.23. RFC 1747使用SMIv2的SNA数据链路控制（SDLC）的托管对象定义
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.26. RFC 2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2
5.26. RFC 2006使用SMIv2为IP移动性支持定义托管对象
This document defines a MIB for the Mobile IPv4. Without enumeration, let it be stated that a new MIB for IPv6 Mobility is required.
本文档定义了移动IPv4的MIB。在没有枚举的情况下，可以说需要一个用于IPv6移动的新MIB。
5.27. RFC 2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2
5.27. 使用SMIv2的互联网协议RFC 2011 SNMPv2管理信息库
Approximately 1/3 of the objects defined in this document are IPv4- dependent. New objects need to be defined to support IPv6.
本文档中定义的对象中大约有1/3依赖于IPv4。需要定义新对象以支持IPv6。
5.28. RFC 2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2
5.28. 使用SMIv2的传输控制协议的RFC 2012 SNMPv2管理信息库
A number of object definitions in this MIB assumes IPv4 addresses, as is noted in the note reproduced below:
此MIB中的许多对象定义采用IPv4地址，如下所示：
IESG Note:
IESG注：
The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses.
IP、UDP和TCP MIB模块当前仅支持IPv4。这三个模块使用定义为长度为4的八位字节字符串的IpAddress类型来表示IPv4 32位internet地址。（参见RFC 1902，SNMPv2的SMI。）它们不支持新的128位IPv6互联网地址。
5.29. RFC 2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2
5.29. 使用SMIv2的用户数据报协议的RFC 2013 SNMPv2管理信息库
A number of object definitions in this MIB assumes IPv4 addresses, as is noted in the note reproduced below:
此MIB中的许多对象定义采用IPv4地址，如下所示：
IESG Note:
IESG注：
The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses.
IP、UDP和TCP MIB模块当前仅支持IPv4。这三个模块使用定义为长度为4的八位字节字符串的IpAddress类型来表示IPv4 32位internet地址。（参见RFC 1902，SNMPv2的SMI。）它们不支持新的128位IPv6互联网地址。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.31. RFC 2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2
5.31. 使用SMIv2的RFC 2021远程网络监控管理信息库版本2
The following objects are defined:
定义了以下对象：
addressMapNetworkAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this relation.
addressMapNetworkAddress对象类型语法八位字符串MAX-ACCESS不可访问状态当前描述“此关系的网络地址。
This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index.
这表示为一个八位字符串，具有特定的语义和长度，由索引的ProtocolDirLocaliIndex组件标识。
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { addressMapEntry 2 }
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { addressMapEntry 2 }
nlHostAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this nlHostEntry.
nlHostAddress对象类型语法八位字符串MAX-ACCESS不可访问状态当前描述“此nlHostEntry的网络地址。
This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index.
这表示为一个八位字符串，具有特定的语义和长度，由索引的ProtocolDirLocaliIndex组件标识。
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlHostEntry 2 }
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlHostEntry 2 }
nlMatrixSDSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixSDEntry.
nlMatrixSDSourceAddress对象类型语法八位字符串MAX-ACCESS不可访问状态当前描述“此NLMATRIXSENTRY的网络源地址。
This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index.
这表示为一个八位字符串，具有特定的语义和长度，由索引的ProtocolDirLocaliIndex组件标识。
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixSDEntry 2 }
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixSDEntry 2 }
nlMatrixSDDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixSDEntry.
nlMatrixSDDestAddress对象类型语法八位字符串MAX-ACCESS不可访问状态当前描述“此NLMATRIXSENTRY的网络目标地址。
This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index.
这表示为一个八位字符串，具有特定的语义和长度，由索引的ProtocolDirLocaliIndex组件标识。
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixSDEntry 3 }
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixSDEntry 3 }
nlMatrixDSSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixDSEntry.
nlMatrixDSSourceAddress对象类型语法八位字符串MAX-ACCESS不可访问状态当前描述“此NLMatrixSentry的网络源地址。
This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index.
这表示为一个八位字符串，具有特定的语义和长度，由索引的ProtocolDirLocaliIndex组件标识。
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixDSEntry 2 }
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixDSEntry 2 }
nlMatrixDSDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixDSEntry.
nlMatrixDSDestAddress对象类型语法八位字符串MAX-ACCESS不可访问状态当前描述“此nlMatrixDSEntry的网络目标地址。
This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index.
这表示为一个八位字符串，具有特定的语义和长度，由索引的ProtocolDirLocaliIndex组件标识。
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixDSEntry 3 }
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixDSEntry 3 }
nlMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only
nlMatrixTopNSourceAddress对象类型语法八位字符串MAX-ACCESS只读
STATUS current DESCRIPTION "The network layer address of the source host in this conversation.
STATUS current DESCRIPTION“此对话中源主机的网络层地址。
This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex.
这表示为八位字节字符串，其特定语义和长度由关联的NLMatrixTopnProtocolDirLocaliIndex标识。
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixTopNEntry 3 }
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixTopNEntry 3 }
nlMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation.
nlMatrixTopNDestAddress对象类型语法八位字符串MAX-ACCESS只读状态当前描述“此对话中目标主机的网络层地址。
This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex.
这表示为八位字节字符串，其特定语义和长度由关联的NLMatrixTopnProtocolDirLocaliIndex标识。
For example, if the nlMatrixTopNProtocolDirLocalIndex
indicates an encapsulation of ip, this object is encoded as a
length octet of 4, followed by the 4 octets of the ip
address, in network byte order."
::= { nlMatrixTopNEntry 4 }
For example, if the nlMatrixTopNProtocolDirLocalIndex
indicates an encapsulation of ip, this object is encoded as a
length octet of 4, followed by the 4 octets of the ip
address, in network byte order."
::= { nlMatrixTopNEntry 4 }
alMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex.
alMatrixTopNSourceAddress对象类型语法八位字节字符串MAX-ACCESS只读状态当前描述“此对话中源主机的网络层地址。此地址表示为八位字节字符串，其特定语义和长度由关联的alMatrixTopNProtocolDirLocalIndex标识。
For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order."
例如，如果ALMATRIXTOPNPROTOCOLDIRLOCINDEX指示ip的封装，则此对象被编码为长度为4的八位字节，后跟ip地址的4个八位字节，以网络字节顺序排列。”
::= { alMatrixTopNEntry 3 }
::= { alMatrixTopNEntry 3 }
alMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation.
alMatrixTopNDestAddress对象类型语法八位字符串MAX-ACCESS只读状态当前描述“此对话中目标主机的网络层地址。
This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex.
这表示为八位字节字符串，具有特定的语义和长度，由关联的AlmatrixTopnProtocolDirLocaliIndex标识。
For example, if the alMatrixTopNProtocolDirLocalIndex
indicates an encapsulation of ip, this object is encoded as a
length octet of 4, followed by the 4 octets of the ip
address, in network byte order."
::= { alMatrixTopNEntry 4 }
For example, if the alMatrixTopNProtocolDirLocalIndex
indicates an encapsulation of ip, this object is encoded as a
length octet of 4, followed by the 4 octets of the ip
address, in network byte order."
::= { alMatrixTopNEntry 4 }
trapDestProtocol OBJECT-TYPE
SYNTAX INTEGER {
ip(1),
ipx(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The protocol with which to send this trap."
::= { trapDestEntry 3 }
trapDestProtocol OBJECT-TYPE
SYNTAX INTEGER {
ip(1),
ipx(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The protocol with which to send this trap."
::= { trapDestEntry 3 }
trapDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The address to send traps on behalf of this entry.
TrapDesAddress对象类型语法八位字符串MAX-ACCESS read create STATUS current DESCRIPTION“代表此项发送陷阱的地址。
If the associated trapDestProtocol object is equal to ip(1),
the encoding of this object is the same as the snmpUDPAddress
textual convention in [RFC1906]:
-- for a SnmpUDPAddress of length 6:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
-- 5-6 UDP-port network-byte order
If the associated trapDestProtocol object is equal to ip(1),
the encoding of this object is the same as the snmpUDPAddress
textual convention in [RFC1906]:
-- for a SnmpUDPAddress of length 6:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
-- 5-6 UDP-port network-byte order
If the associated trapDestProtocol object is equal to ipx(2),
如果关联的trapDestProtocol对象等于ipx（2），
the encoding of this object is the same as the snmpIPXAddress
textual convention in [RFC1906]:
-- for a SnmpIPXAddress of length 12:
--
-- octets contents encoding
-- 1-4 network-number network-byte order
-- 5-10 physical-address network-byte order
-- 11-12 socket-number network-byte order
the encoding of this object is the same as the snmpIPXAddress
textual convention in [RFC1906]:
-- for a SnmpIPXAddress of length 12:
--
-- octets contents encoding
-- 1-4 network-number network-byte order
-- 5-10 physical-address network-byte order
-- 11-12 socket-number network-byte order
This object may not be modified if the associated
trapDestStatus object is equal to active(1)."
::= { trapDestEntry 4 }
This object may not be modified if the associated
trapDestStatus object is equal to active(1)."
::= { trapDestEntry 4 }
All of the object definitions above (except trapDestProtocol) mention only IPv4 addresses. However, since they use a SYNTAX of OCTET STRING, they should work fine for IPv6 addresses. A new legitimate value of trapDestProtocol (i.e., SYNTAX addition of ipv6(3) should make this specification functional for IPv6.
上述所有对象定义（trapDestProtocol除外）仅提及IPv4地址。但是，由于它们使用八位字节字符串的语法，因此对于IPv6地址，它们应该可以正常工作。trapDestProtocol的一个新合法值（即ipv6（3）的语法添加）应使本规范适用于ipv6。
5.32. RFC 2024 Definitions of Managed Objects for Data Link Switching using SMIv2
5.32. RFC 2024使用SMIv2进行数据链路交换的托管对象定义
The following textual conventions are defined:
定义了以下文本约定：
TAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
For dlswTCPDomain, a TAddress is 4 octets long,
containing the IP-address in network-byte order."
SYNTAX OCTET STRING (SIZE (0..255))
TAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
For dlswTCPDomain, a TAddress is 4 octets long,
containing the IP-address in network-byte order."
SYNTAX OCTET STRING (SIZE (0..255))
-- DLSw over TCP
dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 }
-- for an IP address of length 4:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
--
DlswTCPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents the IP address of a DLSw which uses
TCP as a transport protocol."
SYNTAX OCTET STRING (SIZE (4))
-- DLSw over TCP
dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 }
-- for an IP address of length 4:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
--
DlswTCPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents the IP address of a DLSw which uses
TCP as a transport protocol."
SYNTAX OCTET STRING (SIZE (4))
Additionally there are many object definitions that use a SYNTAX of TAddress within the document. Interestingly the SYNTAX for TAddress is an OCTET string of up to 256 characters. It could easily accommodate a similar hybrid format for IPv6 addresses.
此外，文档中还有许多使用TadAddress语法的对象定义。有趣的是，TAddress的语法是最多256个字符的八位字符串。它可以很容易地为IPv6地址提供类似的混合格式。
A new OID to enhance functionality for DlswTCPAddress could be added to support IPv6 addresses.
可以添加一个新的OID来增强DlswTCPAddress的功能，以支持IPv6地址。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
The MIB module's main conceptual table ipCidrRouteTable uses IPv4 addresses as index objects and is therefore incapable of representing an IPv6 forwarding information base. A new conceptual table needs to be defined to support IPv6 addresses.
MIB模块的主概念表IPCIDROUTTETABLE使用IPv4地址作为索引对象，因此无法表示IPv6转发信息库。需要定义新的概念表以支持IPv6地址。
5.35. RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 802
5.35. RFC 2108使用SMIv2 802的IEEE 802.3中继器设备的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.37. RFC 2128 Dial Control Management Information Base using SMIv2
5.37. 使用SMIv2的RFC 2128拨号控制管理信息库
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
All of the relevant object definitions in this MIB have options for both IPv4 and IPv6. There are no IPv4 dependencies in this specification.
此MIB中的所有相关对象定义都具有IPv4和IPv6选项。此规范中不存在IPv4依赖项。
5.39. RFC 2213 Integrated Services Management Information Base using SMIv2
5.39. 使用SMIv2的RFC 2213集成服务管理信息库
This MIB is IPv6 aware and therefore there are no IPv4 dependencies in this specification.
此MIB支持IPv6，因此此规范中不存在IPv4依赖项。
5.40. RFC 2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2
5.40. RFC 2214使用SMIv2的集成服务管理信息库保证服务扩展
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.43. RFC 2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices
5.43. RFC 2266 IEEE 802.12中继器设备的受管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.44. RFC 2287 Definitions of System-Level Managed Objects for Applications
5.44. RFC 2287应用程序系统级托管对象的定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.45. RFC 2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)
5.45. RFC 2320使用SMIv2（IPOA-MIB）的ATM上传统IP和ARP的托管对象定义
This MIB is wholly dependent on IPv4. A new MIB for IPv6 is required to provide the same functionality.
此MIB完全依赖于IPv4。IPv6需要一个新的MIB来提供相同的功能。
5.46. RFC 2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
5.46. RFC 2417基于UNI 3.0/3.1的ATM网络上多播的托管对象定义
This MIB is wholly dependent on IPv4. A new MIB for IPv6 is required to provide the same functionality.
此MIB完全依赖于IPv4。IPv6需要一个新的MIB来提供相同的功能。
5.47. RFC 2452 IP Version 6 Management Information Base for the Transmission Control Protocol
5.47. 传输控制协议的RFC 2452 IP版本6管理信息库
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
本RFC记录了一个即将淘汰的IPv6 MIB，本次讨论中不予以考虑。
5.48. RFC 2454 IP Version 6 Management Information Base for the User Datagram Protocol
5.48. 用户数据报协议的RFC 2454 IP版本6管理信息库
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
本RFC记录了一个即将淘汰的IPv6 MIB，本次讨论中不予以考虑。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.51. RFC 2457 Definitions of Managed Objects for Extended Border Node
5.51. RFC 2457扩展边界节点的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.52. RFC 2465 Management Information Base for IP Version 6: Textual Conventions and General Group
5.52. RFC 2465 IP版本6的管理信息库：文本约定和一般组
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
本RFC记录了一个即将淘汰的IPv6 MIB，本次讨论中不予以考虑。
5.53. RFC 2466 Management Information Base for IP Version 6: ICMPv6 Group
5.53. IP版本6:ICMPv6组的RFC 2466管理信息库
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
本RFC记录了一个即将淘汰的IPv6 MIB，本次讨论中不予以考虑。
5.54. RFC 2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type
5.54. RFC 2494 DS0和DS0捆绑包接口类型的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.55. RFC 2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types
5.55. RFC 2495 DS1、E1、DS2和E2接口类型的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.56. RFC 2496 Definitions of Managed Object for the DS3/E3 Interface Type
5.56. RFC 2496 DS3/E3接口类型的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.58. RFC 2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks
5.58. RFC 2513用于控制面向连接网络记帐信息的收集和存储的托管对象
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.59. RFC 2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management
5.59. RFC 2514 ATM管理的文本约定和对象标识定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This MIB defines the following objects:
此MIB定义以下对象：
AtmInterfaceConfEntry ::= SEQUENCE {
atmInterfaceMaxVpcs INTEGER,
atmInterfaceMaxVccs INTEGER,
atmInterfaceConfVpcs INTEGER,
atmInterfaceConfVccs INTEGER,
atmInterfaceMaxActiveVpiBits INTEGER,
atmInterfaceMaxActiveVciBits INTEGER,
atmInterfaceIlmiVpi AtmVpIdentifier,
atmInterfaceIlmiVci AtmVcIdentifier,
atmInterfaceAddressType INTEGER,
atmInterfaceAdminAddress AtmAddr,
atmInterfaceMyNeighborIpAddress IpAddress,
atmInterfaceMyNeighborIfName DisplayString,
atmInterfaceCurrentMaxVpiBits INTEGER,
atmInterfaceCurrentMaxVciBits INTEGER,
atmInterfaceSubscrAddress AtmAddr
}
AtmInterfaceConfEntry ::= SEQUENCE {
atmInterfaceMaxVpcs INTEGER,
atmInterfaceMaxVccs INTEGER,
atmInterfaceConfVpcs INTEGER,
atmInterfaceConfVccs INTEGER,
atmInterfaceMaxActiveVpiBits INTEGER,
atmInterfaceMaxActiveVciBits INTEGER,
atmInterfaceIlmiVpi AtmVpIdentifier,
atmInterfaceIlmiVci AtmVcIdentifier,
atmInterfaceAddressType INTEGER,
atmInterfaceAdminAddress AtmAddr,
atmInterfaceMyNeighborIpAddress IpAddress,
atmInterfaceMyNeighborIfName DisplayString,
atmInterfaceCurrentMaxVpiBits INTEGER,
atmInterfaceCurrentMaxVciBits INTEGER,
atmInterfaceSubscrAddress AtmAddr
}
atmInterfaceMyNeighborIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP address of the neighbor system connected to
the far end of this interface, to which a Network
Management Station can send SNMP messages, as IP
datagrams sent to UDP port 161, in order to access
network management information concerning the
operation of that system. Note that the value
of this object may be obtained in different ways,
e.g., by manual configuration, or through ILMI
interaction with the neighbor system."
::= { atmInterfaceConfEntry 11 }
atmInterfaceMyNeighborIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP address of the neighbor system connected to
the far end of this interface, to which a Network
Management Station can send SNMP messages, as IP
datagrams sent to UDP port 161, in order to access
network management information concerning the
operation of that system. Note that the value
of this object may be obtained in different ways,
e.g., by manual configuration, or through ILMI
interaction with the neighbor system."
::= { atmInterfaceConfEntry 11 }
atmInterfaceConfGroup2 OBJECT-GROUP
OBJECTS {
atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
atmInterfaceConfVpcs, atmInterfaceConfVccs,
atmInterfaceMaxActiveVpiBits,
atmInterfaceMaxActiveVciBits,
atmInterfaceIlmiVpi,
atmInterfaceIlmiVci,
atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName,
atmInterfaceCurrentMaxVpiBits,
atmInterfaceCurrentMaxVciBits,
atmInterfaceSubscrAddress }
STATUS current
DESCRIPTION
"A collection of objects providing configuration
information about an ATM interface."
::= { atmMIBGroups 10 }
atmInterfaceConfGroup2 OBJECT-GROUP
OBJECTS {
atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
atmInterfaceConfVpcs, atmInterfaceConfVccs,
atmInterfaceMaxActiveVpiBits,
atmInterfaceMaxActiveVciBits,
atmInterfaceIlmiVpi,
atmInterfaceIlmiVci,
atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName,
atmInterfaceCurrentMaxVpiBits,
atmInterfaceCurrentMaxVciBits,
atmInterfaceSubscrAddress }
STATUS current
DESCRIPTION
"A collection of objects providing configuration
information about an ATM interface."
::= { atmMIBGroups 10 }
Clearly a subsequent revision of this MIB module should define equivalent IPv6 objects.
显然，此MIB模块的后续版本应该定义等效的IPv6对象。
5.61. RFC 2561 Base Definitions of Managed Objects for TN3270E Using SMIv2
5.61. RFC 2561使用SMIv2的TN3270E托管对象的基本定义
The document states:
该文件指出：
The MIB defined by this memo supports use of both IPv4 and IPv6 addressing.
此备忘录定义的MIB支持使用IPv4和IPv6寻址。
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
5.62. RFC 2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2
5.62. RFC 2562使用SMIv2收集TN3270E响应时间的协议和托管对象定义
This MIB module inherits IP version-independence by virtue of importing the appropriate definitions from RFC 2561.
此MIB模块通过从RFC2561导入适当的定义来继承IP版本独立性。
The following textual convention is defined:
定义了以下文本约定：
ApplTAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
ApplTAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
For snmpUDPDomain, an ApplTAddress is 6 octets long,
对于snmpUDPDomain，ApplTAddress的长度为6个八位字节，
the initial 4 octets containing the IP-address in network-byte order and the last 2 containing the UDP port in network-byte order. Consult 'Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)' for further information on snmpUDPDomain." SYNTAX OCTET STRING (SIZE (0..255))
最初的4个八位字节以网络字节顺序包含IP地址，最后2个八位字节以网络字节顺序包含UDP端口。有关snmpUDPDomain的更多信息，请参阅“简单网络管理协议（SNMPv2）版本2的传输映射”。语法八位字符串（大小（0..255））
A new TC should be defined to handle IPv6 addresses.
应该定义一个新的TC来处理IPv6地址。
5.64. RFC 2584 Definitions of Managed Objects for APPN/HPR in IP Networks
5.64. RFC 2584 IP网络中APPN/HPR的托管对象定义
Many of the object definitions described in this document assume the use of the IPv4 only TOS header bits. It is therefore IPv4-only in nature and will not support IPv6.
本文档中描述的许多对象定义都假定只使用IPv4 TOS头位。因此，它本质上只是IPv4，不支持IPv6。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.67. RFC 2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0
5.67. RFC 2613用于交换网络的远程网络监控MIB扩展版本1.0
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This RFC defines the following objects:
此RFC定义了以下对象：
RadiusAuthServerEntry ::= SEQUENCE {
radiusAuthServerIndex Integer32,
radiusAuthServerAddress IpAddress,
radiusAuthClientServerPortNumber Integer32,
radiusAuthClientRoundTripTime TimeTicks,
radiusAuthClientAccessRequests Counter32,
radiusAuthClientAccessRetransmissions Counter32,
radiusAuthClientAccessAccepts Counter32,
radiusAuthClientAccessRejects Counter32,
radiusAuthClientAccessChallenges Counter32,
radiusAuthClientMalformedAccessResponses Counter32,
radiusAuthClientBadAuthenticators Counter32,
radiusAuthClientPendingRequests Gauge32,
radiusAuthClientTimeouts Counter32,
radiusAuthClientUnknownTypes Counter32,
RadiusAuthServerEntry ::= SEQUENCE {
radiusAuthServerIndex Integer32,
radiusAuthServerAddress IpAddress,
radiusAuthClientServerPortNumber Integer32,
radiusAuthClientRoundTripTime TimeTicks,
radiusAuthClientAccessRequests Counter32,
radiusAuthClientAccessRetransmissions Counter32,
radiusAuthClientAccessAccepts Counter32,
radiusAuthClientAccessRejects Counter32,
radiusAuthClientAccessChallenges Counter32,
radiusAuthClientMalformedAccessResponses Counter32,
radiusAuthClientBadAuthenticators Counter32,
radiusAuthClientPendingRequests Gauge32,
radiusAuthClientTimeouts Counter32,
radiusAuthClientUnknownTypes Counter32,
radiusAuthClientPacketsDropped Counter32 }
RadiusAuthClientPackets拦截计数器32}
radiusAuthServerAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of the RADIUS authentication server
referred to in this table entry."
::= { radiusAuthServerEntry 2 }
radiusAuthServerAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of the RADIUS authentication server
referred to in this table entry."
::= { radiusAuthServerEntry 2 }
There needs to be an update to allow an IPv6 based object for this value.
需要进行更新以允许此值使用基于IPv6的对象。
This MIB defines the followings objects:
此MIB定义了以下对象：
RadiusAuthClientEntry ::= SEQUENCE {
radiusAuthClientIndex Integer32,
radiusAuthClientAddress IpAddress,
radiusAuthClientID SnmpAdminString,
radiusAuthServAccessRequests Counter32,
radiusAuthServDupAccessRequests Counter32,
radiusAuthServAccessAccepts Counter32,
radiusAuthServAccessRejects Counter32,
radiusAuthServAccessChallenges Counter32,
radiusAuthServMalformedAccessRequests Counter32,
radiusAuthServBadAuthenticators Counter32,
radiusAuthServPacketsDropped Counter32,
radiusAuthServUnknownTypes Counter32
}
RadiusAuthClientEntry ::= SEQUENCE {
radiusAuthClientIndex Integer32,
radiusAuthClientAddress IpAddress,
radiusAuthClientID SnmpAdminString,
radiusAuthServAccessRequests Counter32,
radiusAuthServDupAccessRequests Counter32,
radiusAuthServAccessAccepts Counter32,
radiusAuthServAccessRejects Counter32,
radiusAuthServAccessChallenges Counter32,
radiusAuthServMalformedAccessRequests Counter32,
radiusAuthServBadAuthenticators Counter32,
radiusAuthServPacketsDropped Counter32,
radiusAuthServUnknownTypes Counter32
}
radiusAuthClientAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The NAS-IP-Address of the RADIUS authentication client
referred to in this table entry."
::= { radiusAuthClientEntry 2 }
radiusAuthClientAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The NAS-IP-Address of the RADIUS authentication client
referred to in this table entry."
::= { radiusAuthClientEntry 2 }
This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses.
需要弃用此对象，并将其替换为同时支持IPv4和IPv6地址的对象。
The only objects in the version of RPSL that deal with IP addresses are defined as:
RPSL版本中唯一处理IP地址的对象定义为：
<ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses.
<ipv4地址>ipv4地址表示为由0到255之间的四个整数组成的序列，由字符点“.”分隔。例如，128.9.128.5表示有效的IPv4地址。在本文档的其余部分中，我们可以将IPv4地址称为IP地址。
<address-prefix> An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings containing four integers.
<address prefix>地址前缀表示为IPv4地址，后跟字符斜杠“/”和0到32之间的整数。以下是有效的地址前缀：128.9.128.5/32、128.9.0.0/16、0.0.0.0/0；以下地址前缀无效：0/0、128.9/16，因为0或128.9不是包含四个整数的字符串。
There seems to be an awareness of IPv6 because of the terminology but it is not specifically defined. Therefore additional objects for IPv6 addresses and prefixes need to be defined.
由于术语的原因，人们似乎意识到了IPv6，但并未对其进行具体定义。因此，需要定义IPv6地址和前缀的其他对象。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
The Abstract of this document says:
这份文件的摘要说：
This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs.
此备忘录定义了一个管理信息库（MIB），用于Internet社区中的网络管理协议。特别是，它描述了用于通过IPv4网络管理任何类型隧道的托管对象。扩展MIB可设计用于管理特定于协议的对象。同样，扩展MIB可以设计用于管理特定于安全性的对象。此MIB不支持非IPv4网络（包括IPv6网络）上的隧道。此类隧道的管理可由其他MIB支持。
A similar MIB for tunneling over IPv6 should be defined.
应该为IPv6上的隧道定义类似的MIB。
5.73. RFC 2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems
5.73. RFC 2669符合DOCSIS标准的电缆调制解调器和电缆调制解调器终端系统的DOCSIS电缆设备MIB电缆设备管理信息库
This document states:
该文件规定：
Please note that the DOCSIS 1.0 standard only requires Cable Modems to implement SNMPv1 and to process IPv4 customer traffic. Design choices in this MIB reflect those requirements. Future versions of the DOCSIS standard are expected to require support for SNMPv3 and IPv6 as well.
请注意，DOCSIS 1.0标准仅要求电缆调制解调器来实现SNMPv1和处理IPv4客户流量。此MIB中的设计选择反映了这些需求。DOCSIS标准的未来版本预计也需要对SNMPv3和IPv6的支持。
5.74. RFC 2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces
5.74. RFC 2670 MCNS/DOCSIS兼容射频接口的射频（RF）接口管理信息库
This MIB defines the following objects:
此MIB定义以下对象：
DocsIfCmtsCmStatusEntry ::= SEQUENCE {
docsIfCmtsCmStatusIndex Integer32,
docsIfCmtsCmStatusMacAddress MacAddress,
docsIfCmtsCmStatusIpAddress IpAddress,
docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero,
docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero,
docsIfCmtsCmStatusRxPower TenthdBmV,
docsIfCmtsCmStatusTimingOffset Unsigned32,
docsIfCmtsCmStatusEqualizationData OCTET STRING,
docsIfCmtsCmStatusValue INTEGER,
docsIfCmtsCmStatusUnerroreds Counter32,
docsIfCmtsCmStatusCorrecteds Counter32,
docsIfCmtsCmStatusUncorrectables Counter32,
docsIfCmtsCmStatusSignalNoise TenthdB,
docsIfCmtsCmStatusMicroreflections Integer32
}
DocsIfCmtsCmStatusEntry ::= SEQUENCE {
docsIfCmtsCmStatusIndex Integer32,
docsIfCmtsCmStatusMacAddress MacAddress,
docsIfCmtsCmStatusIpAddress IpAddress,
docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero,
docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero,
docsIfCmtsCmStatusRxPower TenthdBmV,
docsIfCmtsCmStatusTimingOffset Unsigned32,
docsIfCmtsCmStatusEqualizationData OCTET STRING,
docsIfCmtsCmStatusValue INTEGER,
docsIfCmtsCmStatusUnerroreds Counter32,
docsIfCmtsCmStatusCorrecteds Counter32,
docsIfCmtsCmStatusUncorrectables Counter32,
docsIfCmtsCmStatusSignalNoise TenthdB,
docsIfCmtsCmStatusMicroreflections Integer32
}
docsIfCmtsCmStatusIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"IP address of this Cable Modem. If the Cable Modem has no
IP address assigned, or the IP address is unknown, this
object returns a value of 0.0.0.0. If the Cable Modem has
multiple IP addresses, this object returns the IP address
associated with the Cable interface."
::= { docsIfCmtsCmStatusEntry 3 }
docsIfCmtsCmStatusIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"IP address of this Cable Modem. If the Cable Modem has no
IP address assigned, or the IP address is unknown, this
object returns a value of 0.0.0.0. If the Cable Modem has
multiple IP addresses, this object returns the IP address
associated with the Cable interface."
::= { docsIfCmtsCmStatusEntry 3 }
This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses.
需要弃用此对象，并将其替换为同时支持IPv4和IPv6地址的对象。
5.75. RFC 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions
5.75. RFC 2674具有流量类、多播过滤和虚拟LAN扩展的网桥的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.76. RFC 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)
5.76. RFC 2677 NBMA下一跳解析协议（NHRP）的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
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依赖项。
Although the examples in the document are for IPv4 transport only, there is no IPv4 dependency in the AgentX protocol itself.
尽管文档中的示例仅适用于IPv4传输，但AgentX协议本身中没有IPv4依赖项。
5.82. RFC 2742 Definitions of Managed Objects for Extensible SNMP Agents
5.82. RFC 2742可扩展SNMP代理的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.86. RFC 2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol
5.86. RFC 2787虚拟路由器冗余协议的托管对象定义
As stated in the Overview section:
如概述部分所述：
Since the VRRP protocol is intended for use with IPv4 routers only, this MIB uses the SYNTAX for IP addresses which is specific to IPv4. Thus, changes will be required for this MIB to interoperate in an IPv6 environment.
由于VRRP协议仅用于IPv4路由器，因此此MIB使用特定于IPv4的IP地址语法。因此，需要更改此MIB才能在IPv6环境中进行互操作。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.89. RFC 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard
5.89. RFC 2837光纤通道标准中结构元素的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.90. RFC 2856 Textual Conventions for Additional High Capacity Data Types
5.90. RFC 2856其他高容量数据类型的文本约定
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.91. RFC 2864 The Inverted Stack Table Extension to the Interfaces Group MIB
5.91. RFC 2864接口组MIB的反向堆栈表扩展
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.92. RFC 2895 Remote Network Monitoring MIB Protocol Identifier Reference
5.92. RFC 2895远程网络监控MIB协议标识符参考
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.93. RFC 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
5.93. RFC 2925远程Ping、Traceroute和查找操作的托管对象定义
This MIB mostly is IPv4 and IPv6 aware. There are a few assumptions that are problems, though. In the following object definitions:
此MIB主要支持IPv4和IPv6。不过，有一些假设是有问题的。在以下对象定义中：
pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create
pingCtlDataSize对象类型语法Unsigned32（0..65507）单位“八位字节”MAX-ACCESS读取创建
STATUS current
DESCRIPTION
"Specifies the size of the data portion to be
transmitted in a ping operation in octets. A ping
request is usually an ICMP message encoded
into an IP packet. An IP packet has a maximum size
of 65535 octets. Subtracting the size of the ICMP
or UDP header (both 8 octets) and the size of the IP
header (20 octets) yields a maximum size of 65507
octets."
DEFVAL { 0 }
::= { pingCtlEntry 5 }
STATUS current
DESCRIPTION
"Specifies the size of the data portion to be
transmitted in a ping operation in octets. A ping
request is usually an ICMP message encoded
into an IP packet. An IP packet has a maximum size
of 65535 octets. Subtracting the size of the ICMP
or UDP header (both 8 octets) and the size of the IP
header (20 octets) yields a maximum size of 65507
octets."
DEFVAL { 0 }
::= { pingCtlEntry 5 }
traceRouteCtlDataSize OBJECT-TYPE
SYNTAX Unsigned32 (0..65507)
UNITS "octets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the size of the data portion of a traceroute
request in octets. A traceroute request is essentially
transmitted by encoding a UDP datagram into a
IP packet. So subtracting the size of a UDP header
(8 octets) and the size of a IP header (20 octets)
yields a maximum of 65507 octets."
DEFVAL { 0 }
::= { traceRouteCtlEntry 6 }
traceRouteCtlDataSize OBJECT-TYPE
SYNTAX Unsigned32 (0..65507)
UNITS "octets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the size of the data portion of a traceroute
request in octets. A traceroute request is essentially
transmitted by encoding a UDP datagram into a
IP packet. So subtracting the size of a UDP header
(8 octets) and the size of a IP header (20 octets)
yields a maximum of 65507 octets."
DEFVAL { 0 }
::= { traceRouteCtlEntry 6 }
The DESCRIPTION clauses need to be updated to remove the IPv4 dependencies.
需要更新描述子句以删除IPv4依赖项。
This specification is only defined for IPv4 and a similar MIB must be defined for IPv6.
此规范仅为IPv4定义，必须为IPv6定义类似的MIB。
As stated in this document:
如本文件所述：
Since IGMP is specific to IPv4, this MIB does not support management of equivalent functionality for other address families, such as IPv6.
由于IGMP特定于IPv4，因此此MIB不支持管理其他地址系列（如IPv6）的等效功能。
5.96. RFC 2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients
5.96. RFC 2940通用开放策略服务（COPS）协议客户端的托管对象定义
This MIB is both IPv4 and IPv6 aware and needs no changes.
此MIB支持IPv4和IPv6，无需更改。
5.97. RFC 2954 Definitions of Managed Objects for Frame Relay Service
5.97. RFC 2954帧中继服务的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.98. RFC 2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function
5.98. RFC 2955监控帧中继/ATM PVC业务互通功能的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.100. RFC 2981 Event MIB
5.100. RFC 2981事件MIB
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.101. RFC 2982 Distributed Management Expression MIB
5.101. RFC 2982分布式管理表达式MIB
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.102. RFC 3014 Notification Log MIB
5.102. RFC 3014通知日志MIB
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.103. RFC 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol
5.103. 多播侦听器发现协议的RFC 3019 IP版本6管理信息库
This is an IPv6 related document and is not discussed in this document.
这是一份与IPv6相关的文档，本文档中没有讨论。
5.104. RFC 3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function
5.104. RFC 3020用于监视和控制UNI/NNI多链路帧中继功能的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.105. RFC 3055 Management Information Base for the PINT Services Architecture
5.105. PINT服务体系结构的RFC 3055管理信息库
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.106. RFC 3060 Policy Core Information Model -- Version 1 Specification (CIM)
5.106. RFC 3060策略核心信息模型--版本1规范（CIM）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.107. RFC 3084 COPS Usage for Policy Provisioning (COPS-PR)
5.107. RFC 3084用于策略设置的COPS使用（COPS-PR）
This specification builds on RFC 2748, and is both IPv4 and IPv6 capable. The specification defines a sample filter in section 4.3, which has "ipv4" in it.
该规范建立在RFC 2748之上，支持IPv4和IPv6。该规范在第4.3节中定义了一个示例过滤器，其中包含“ipv4”。
5.108. RFC 3165 Definitions of Managed Objects for the Delegation of Management Scripts
5.108. RFC 3165管理脚本委托的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.109. RFC 3231 Definitions of Managed Objects for Scheduling Management Operations
5.109. RFC 3231调度管理操作的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.110. RFC 3291 Textual Conventions for Internet Network Addresses
5.110. RFC 3291 Internet网络地址的文本约定
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.111. RFC 3635 Definitions of Managed Objects for the Ethernet-like Interface Types
5.111. RFC 3635类以太网接口类型的托管对象定义
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.112. RFC 3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
5.112. RFC 3636 IEEE 802.3介质连接单元（MAU）的受管对象定义
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上没有大规模实现或使用的协议。它们通常在性质上是恰当的，或者在有限的领域中使用。为了允许潜在的互操作性或其他一些潜在的有用场景，它们被记录到互联网社区中。在少数情况下，它们被作为主流解决方案的替代方案来解决一个公认的问题。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.2. RFC 1224 Techniques for managing asynchronously generated alerts
6.2. RFC 1224用于管理异步生成警报的技术
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.3. RFC 1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)
6.3. RFC 1238 CLNS MIB，用于无连接网络协议（ISO 8473）和终端系统到中间系统（ISO 9542）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.4. RFC 1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0
6.4. RFC 1592简单网络管理协议分布式协议接口版本2.0
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.7. RFC 2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring
6.7. RFC 2758服务级别协议性能监视的托管对象定义
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
6.8. RFC 2786 Diffie-Helman USM Key Management Information Base and Textual Convention
6.8. RFC 2786 Diffie-Helman USM密钥管理信息库和文本约定
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document is specific to IPv4.
本文档特定于IPv4。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
In the initial survey of RFCs, 36 positives were identified out of a total of 153, broken down as follows:
在对RFC的初步调查中，在总共153个样本中确定了36个阳性样本，细分如下：
Standards: 6 out of 15 or 40.00% Draft Standards: 4 out of 15 or 26.67% Proposed Standards: 26 out of 112 or 23.21% Experimental RFCs: 0 out of 11 or 0.00%
标准：15分之6或40.00%标准草案：15分之4或26.67%拟定标准：112分之26或23.21%实验性RFC：11分之0或0.00%
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.
在已确定的协议中，许多协议不需要采取行动，因为它们记录了过时和未使用的协议，而其他协议则记录了相关工作组正在积极更新的协议。此外，还有许多应更新的标准实例，但如果不更新，则不会造成任何运营影响。其余实例记录如下。
RFC 1155 and RFC 1212 (along with the informational document RFC 1215) define SMIv1. These documents have been superseded by RFCs 2578, 2579, and 2580 which define SMIv2. Since SMIv1 is no longer being used as the basis for new IETF MIB modules, the limitations identified in this Internet Standard do not require any action.
RFC 1155和RFC 1212（以及信息文档RFC 1215）定义了SMIv1。这些文件已被定义SMIv2的RFC 2578、2579和2580所取代。由于SMIv1不再用作新IETF MIB模块的基础，因此本互联网标准中确定的限制不需要采取任何措施。
The limitations identified have been addressed, because RFC 1213 has been split into multiple modules which are all IPv6 capable.
已经解决了确定的限制，因为RFC 1213已拆分为多个模块，这些模块都支持IPv6。
This problem is currently being addressed by the Inter Domain Routing (IDR) WG [2].
这个问题目前正由域间路由（IDR）工作组[2]解决。
See Internet Area standards. Once a specification for IPv6 over SMDS is created a new MIB must be defined.
参见互联网区域标准。一旦创建了SMDS上的IPv6规范，就必须定义新的MIB。
There is no updated MIB module to cover the problems outlined. A new MIB module should be defined.
没有更新的MIB模块来解决概述的问题。应定义新的MIB模块。
This problem is currently being addressed by the OSPF WG [3].
OSPF工作组目前正在解决这个问题[3]。
RFC 1906 has been obsoleted by RFC 3417, Transport Mappings for SNMP, and the limitations of this specification have been addressed by that RFC, which defines TCs that can be used to specify transport domains in an IP version-independent way. RFC 3419 recommends that those TCs be used in place of SnmpUDPAddress when IPv6 support is required and for all new applications that are not SNMP-specific.
RFC 1906已被RFC 3417《SNMP的传输映射》淘汰，该RFC已解决了本规范的限制，该RFC定义了可用于以独立于IP版本的方式指定传输域的TC。RFC 3419建议，当需要IPv6支持时，以及对于所有非SNMP特定的新应用程序，使用这些TC代替SnmpUDPAddress。
This problem has not been addressed. If a user requirement for IPv6 over X.25 develops (which is thought to be unlikely) then this MIB module will need to be updated in order to accommodate it.
这个问题没有得到解决。如果用户对IPv6 over X.25的需求增加（这被认为是不可能的），则需要更新此MIB模块以适应它。
There is no updated MIB to cover the problems outlined. A new MIB should be defined.
没有更新的MIB来涵盖概述的问题。应定义新的MIB。
This problem has not been addressed. If a user requirement for IPv6 over Appletalk develops (which is thought to be unlikely) then this MIB module will need to be updated (or a new MIB module will need to be created) in order to accommodate it.
这个问题没有得到解决。如果在Appletalk上开发IPv6的用户需求（这被认为是不可能的），则需要更新此MIB模块（或者需要创建新的MIB模块）以适应它。
7.3.4. The Definitions of Managed Objects for IP Mobility Support using SMIv2 (RFC 2006)
7.3.4. 使用SMIv2为IP移动性支持定义托管对象（RFC 2006）
The problems are being resolved by the MIP6 WG [4].
MIP6工作组正在解决这些问题[4]。
This issue is being resolved by the IPv6 WG [5].
IPv6工作组正在解决此问题[5]。
This issue is being resolved by the IPv6 WG [6].
IPv6工作组正在解决此问题[6]。
This issue is being resolved by the IPv6 WG [7].
IPv6工作组正在解决此问题[7]。
This issue has been brought to the attention of the RMONMIB WG. Currently, there is a work in progress [8] to update RFC 2021, but it does not address the problems that have been identified; it is expected that there will be a resolution in a future version of that document.
已提请RMONMIB工作组注意该问题。目前，有一项更新RFC 2021的工作[8]正在进行，但并未解决已确定的问题；预计该文件的未来版本将有一项决议。
The problems have not been addressed and an updated MIB should be defined.
问题尚未解决，应定义更新的MIB。
This issue is being worked on by the IPv6 WG [9].
IPv6工作组正在研究此问题[9]。
The current version of Classical IP and ARP over ATM (RFC 2225) does not support IPv6. If and when that protocol specification is updated to add IPv6 support, then new MIB objects to represent IPv6 addresses will need to be added to this MIB module.
当前版本的经典IP和ATM上的ARP（RFC2225）不支持IPv6。如果更新该协议规范以添加IPv6支持，则需要将表示IPv6地址的新MIB对象添加到此MIB模块。
The current version of Multicast over UNI 3.0/3.1 ATM (RFC 2022) does not support IPv6. If and when that protocol specification is updated to add IPv6 support, then new MIB objects to represent IPv6 addresses will need to be added to this MIB module.
当前版本的UNI 3.0/3.1 ATM多播（RFC 2022）不支持IPv6。如果更新该协议规范以添加IPv6支持，则需要将表示IPv6地址的新MIB对象添加到此MIB模块。
The AToM MIB WG is currently collecting implementation reports for RFC 2515 and is considering whether to advance, revise, or retire this specification. The problems identified have been brought to the attention of the WG.
AToM MIB工作组目前正在收集RFC 2515的实施报告，并正在考虑是否推进、修订或废止该规范。已提请工作组注意所发现的问题。
The problems identified are not being addressed and a new MIB module may need to be defined.
发现的问题没有得到解决，可能需要定义一个新的MIB模块。
The problems identified are not being addressed and a new MIB module may need to be defined. One possible solution might be to use the RFC 3419 TCs.
发现的问题没有得到解决，可能需要定义一个新的MIB模块。一种可能的解决方案是使用RFC 3419 TCs。
7.3.16. Definitions of Managed Objects for APPN/HPR in IP Networks (RFC 2584)
7.3.16. IP网络中APPN/HPR的托管对象定义（RFC 2584）
The problems identified are not addressed and a new MIB may be defined.
确定的问题未得到解决，可能会定义新的MIB。
The problems have not been addressed and a new MIB should be defined.
这些问题尚未解决，应定义新的MIB。
The problems have not been addressed and a new MIB should be defined.
这些问题尚未解决，应定义新的MIB。
Additional objects must be defined for IPv6 addresses and prefixes.
必须为IPv6地址和前缀定义其他对象。
[10] defines extensions to solve this issue, and it is being considered for publication.
[10] 定义用于解决此问题的扩展，目前正在考虑将其发布。
The issue is being resolved.
这个问题正在得到解决。
This problem is currently being addressed by the IPCDN WG.
IPCDN工作组目前正在解决这个问题。
This problem is currently being addressed by the IPCDN WG [11].
IPCDN工作组目前正在解决这个问题[11]。
The problems have not been addressed and a new MIB may need to be defined.
这些问题尚未解决，可能需要定义新的MIB。
The problems have not been addressed and a new MIB may need to be defined.
这些问题尚未解决，可能需要定义新的MIB。
The problems have not been addressed a new MIB must be defined.
问题尚未解决，必须定义新的MIB。
This problem is currently being addressed by the MAGMA WG [12].
MAGMA WG目前正在解决这个问题[12]。
The problems have not been addressed and a new MIB may need to be defined.
这些问题尚未解决，可能需要定义新的MIB。
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 thank 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 his guidance and collection of comments for the editing of this document. He would further like to thank Juergen Schoenwaelder, Brian Carpenter, Bert Wijnen and especially C. M. Heard for feedback on many points of this document.
编辑Andreas Bergstrom感谢Pekka Savola为本文件的编辑提供指导和收集评论。他还要进一步感谢Juergen Schoenwaelder、Brian Carpenter、Bert Wijnen，特别是C.M.Heard，感谢他们对本文件的许多观点的反馈。
[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] Haas, J. and S. Hares, Editors, "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)", Work in Progress, April 2004.
[2] Haas，J.和S.Hares，编辑，“第四版边界网关协议（BGP-4）的托管对象定义”，正在进行的工作，2004年4月。
[3] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", Work in Progress, April 2004.
[3] Joyal，D.和V.Manral，“OSPFv3管理信息库”，正在进行的工作，2004年4月。
[4] Keeni, G., Koide, K., Nagami, K. and S. Gundavelli, "The Mobile IPv6 MIB", Work in Progress, February 2004.
[4] Keeni，G.，Koide，K.，Nagami，K.和S.Gundavelli，“移动IPv6 MIB”，正在进行的工作，2004年2月。
[5] Routhier, S., Editor, "Management Information Base for the Internet Protocol (IP)", Work in Progress, April 2004.
[5] Routhier，S.，编辑，“互联网协议（IP）管理信息库”，正在进行的工作，2004年4月。
[6] Raghunarayan, R., Editor, "Management Information Base for the Transmission Control Protocol (TCP)", Work in Progress, February 2004.
[6] Raghunarayan，R.，编辑，“传输控制协议（TCP）的管理信息库”，正在进行的工作，2004年2月。
[7] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", Work in Progress, April 2004.
[7] Fenner，B.和J.Flick，“用户数据报协议（UDP）的管理信息库”，正在进行的工作，2004年4月。
[8] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 Using SMIv2", Work in Progress, February 2004.
[8] Waldbusser，S.，“使用SMIv2的远程网络监控管理信息库版本2”，正在进行的工作，2004年2月。
[9] Haberman, B., "IP Forwarding Table MIB", Work in Progress, February 2004.
[9] Haberman，B.，“IP转发表MIB”，正在进行的工作，2004年2月。
[10] Blunk, L., Damas, J., Parent, F. and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", Work in Progress, April 2004.
[10] Blunk，L.，Damas，J.，Parent，F.和A.Robachevsky，“下一代路由策略规范语言（RPSLng）”，正在进行的工作，2004年4月。
[11] Raftus, D. and E. Cardona, Editor, "Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces", Work in Progress, April 2004.
[11] Raftus，D.和E.Cardona，编辑，“DOCSIS 2.0兼容射频接口的射频（RF）接口管理信息库”，正在进行的工作，2004年4月。
[12] Chesterfield, J., Editor, "Multicast Group Membership Discovery MIB", Work in Progress, February 2004.
[12] 切斯特菲尔德，J.，编辑，“多播组成员发现MIB”，正在进行的工作，2004年2月。
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编辑功能的资金目前由互联网协会提供。