Management Information Base (MIB) using SMIv2
There are no IPv4 dependencies in this specification.
5.22. RFC 1742 AppleTalk Management Information Base II
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
}
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
"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 }
5.23. RFC 1747 Definitions of Managed Objects for SNA Data Link
Control (SDLC) using SMIv2
There are no IPv4 dependencies in this specification.
5.24. RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2
There are no IPv4 dependencies in this specification.
5.25. RFC 1759 Printer MIB
There are no IPv4 dependencies in this specification.
5.26. RFC 2006 The Definitions of Managed Objects for IP Mobility
Support using SMIv2
This document defines a MIB for the Mobile IPv4. Without
enumeration, let it be stated that a new MIB for IPv6 Mobility is
required.
5.27. RFC 2011 SNMPv2 Management Information Base for the Internet
Protocol using SMIv2
Approximately 1/3 of the objects defined in this document are IPv4-
dependent. New objects need to be defined to support IPv6.
5.28. RFC 2012 SNMPv2 Management Information Base for the
Transmission Control Protocol using SMIv2
A number of object definitions in this MIB assumes IPv4 addresses, as
is noted in the note reproduced below:
IESG Note:
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.
5.29. RFC 2013 SNMPv2 Management Information Base for the User
Datagram Protocol using SMIv2
A number of object definitions in this MIB assumes IPv4 addresses, as
is noted in the note reproduced below:
IESG Note:
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.
5.30. RFC 2020 IEEE 802.12 Interface MIB
There are no IPv4 dependencies in this specification.
5.31. RFC 2021 Remote Network Monitoring Management Information Base
Version 2 using SMIv2
The following objects are defined:
addressMapNetworkAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network address for this relation.
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the
index.
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.
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
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.
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
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.
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
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.
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
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.
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
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
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 nlMatrixTopNProtocolDirLocalIndex.
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.
This is represented as an octet string with
specific semantics and length as identified
by the associated nlMatrixTopNProtocolDirLocalIndex.
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.
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 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.
This is represented as an octet string with
specific semantics and length as identified
by the associated 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."
::= { 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 }
trapDestAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The address to send traps on behalf of this entry.
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),
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 }
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.
5.32. RFC 2024 Definitions of Managed Objects for Data Link Switching
using 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))
-- 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.
A new OID to enhance functionality for DlswTCPAddress could be added
to support IPv6 addresses.
5.33. RFC 2051 Definitions of Managed Objects for APPC using SMIv2
There are no IPv4 dependencies in this specification.
5.34. RFC 2096 IP Forwarding Table MIB
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.
5.35. RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater
Devices using SMIv2 802
There are no IPv4 dependencies in this specification.
5.36. RFC 2127 ISDN Management Information Base using SMIv2
There are no IPv4 dependencies in this specification.
5.37. RFC 2128 Dial Control Management Information Base using
SMIv2
There are no IPv4 dependencies in this specification.
5.38. RFC 2206 RSVP Management Information Base using SMIv2
All of the relevant object definitions in this MIB have options for
both IPv4 and IPv6. There are no IPv4 dependencies in this
specification.
5.39. RFC 2213 Integrated Services Management Information
Base using SMIv2
This MIB is IPv6 aware and therefore there are no IPv4 dependencies
in this specification.
5.40. RFC 2214 Integrated Services Management Information
Base Guaranteed Service Extensions using SMIv2
There are no IPv4 dependencies in this specification.
5.41. RFC 2232 Definitions of Managed Objects for DLUR using SMIv2
There are no IPv4 dependencies in this specification.
5.42. RFC 2238 Definitions of Managed Objects for HPR using SMIv2
There are no IPv4 dependencies in this specification.
5.43. RFC 2266 Definitions of Managed Objects for IEEE 802.12
Repeater Devices
There are no IPv4 dependencies in this specification.
5.44. RFC 2287 Definitions of System-Level Managed Objects for
Applications
There are no IPv4 dependencies in this specification.
5.45. RFC 2320 Definitions of Managed Objects for Classical IP
and ARP Over ATM Using SMIv2 (IPOA-MIB)
This MIB is wholly dependent on IPv4. A new MIB for IPv6 is required
to provide the same functionality.
5.46. RFC 2417 Definitions of Managed Objects for Multicast
over UNI 3.0/3.1 based ATM Networks
This MIB is wholly dependent on IPv4. A new MIB for IPv6 is required
to provide the same functionality.
5.47. RFC 2452 IP Version 6 Management Information Base for the
Transmission Control Protocol
This RFC documents a soon to be obsoleted IPv6 MIB and is not
considered in this discussion.
5.48. RFC 2454 IP Version 6 Management Information Base for
the User Datagram Protocol
This RFC documents a soon to be obsoleted IPv6 MIB and is not
considered in this discussion.
5.49. RFC 2455 Definitions of Managed Objects for APPN
There are no IPv4 dependencies in this specification.
5.50. RFC 2456 Definitions of Managed Objects for APPN TRAPS
There are no IPv4 dependencies in this specification.
5.51. RFC 2457 Definitions of Managed Objects for Extended Border
Node
There are no IPv4 dependencies in this specification.
5.52. RFC 2465 Management Information Base for IP Version 6:
Textual Conventions and General Group
This RFC documents a soon to be obsoleted IPv6 MIB and is not
considered in this discussion.
5.53. RFC 2466 Management Information Base for IP Version 6:
ICMPv6 Group
This RFC documents a soon to be obsoleted IPv6 MIB and is not
considered in this discussion.
5.54. RFC 2494 Definitions of Managed Objects for the DS0
and DS0 Bundle Interface Type
There are no IPv4 dependencies in this specification.
5.55. RFC 2495 Definitions of Managed Objects for the DS1, E1,
DS2 and E2 Interface Types
There are no IPv4 dependencies in this specification.
5.56. RFC 2496 Definitions of Managed Object for the DS3/E3
Interface Type
There are no IPv4 dependencies in this specification.
5.57. RFC 2512 Accounting Information for ATM Networks
There are no IPv4 dependencies in this specification.
5.58. RFC 2513 Managed Objects for Controlling the Collection
and Storage of Accounting Information for
Connection-Oriented Networks
There are no IPv4 dependencies in this specification.
5.59. RFC 2514 Definitions of Textual Conventions and
OBJECT-IDENTITIES for ATM Management
There are no IPv4 dependencies in this specification.
5.60. RFC 2515 Definitions of Managed Objects for ATM Management
This MIB defines the following objects:
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 }
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.
5.61. RFC 2561 Base Definitions of Managed Objects for TN3270E
Using SMIv2
The document states: