diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3796.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3796.txt')
| -rw-r--r-- | doc/rfc/rfc3796.txt | 2411 |
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc3796.txt b/doc/rfc/rfc3796.txt new file mode 100644 index 0000000..6073de3 --- /dev/null +++ b/doc/rfc/rfc3796.txt @@ -0,0 +1,2411 @@ + + + + + + +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 + +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). + +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. + + + + + + + + + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 1] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +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 + + 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). + + For a full introduction, please see the introduction [1]. + +2. Document Organization + + 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. + + 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. + + + + + +Nesser II & Bergstrom Informational [Page 2] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +3. Full Standards + + Full Internet Standards (most commonly simply referred to as + "Standards") are fully mature protocol specification that are widely + implemented and used throughout the Internet. + +3.1. RFC 1155 Structure of Management Information + + Section 3.2.3.2. IpAddress defines the following: + + This application-wide type represents a 32-bit internet address. + It is represented as an OCTET STRING of length 4, in network + byte-order. + + There are several instances of the use of this definition in the rest + of the document. + +3.2. RFC 1212 Concise MIB definitions + + In section 4.1.6 IpAddress is defined as: + + (6) IpAddress-valued: 4 sub-identifiers, in the familiar + a.b.c.d notation. + +3.3. RFC 1213 Management Information Base + + 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. + +3.4. RFC 2578 Structure of Management Information Version 2 (SMIv2) + + Section 7.1.5 defines the IpAddress data type: + + The IpAddress type represents a 32-bit internet address. It is + represented as an OCTET STRING of length 4, in network byte-order. + + 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. + + Note the deprecated status of this type; see RFC 3291 for details on + the replacement TEXTUAL-CONVENTION definitions. + +3.5. RFC 2579 Textual Conventions for SMIv2 + + There are no IPv4 dependencies in this specification. + + + +Nesser II & Bergstrom Informational [Page 3] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +3.6. RFC 2580 Conformance Statements for SMIv2 + + There are no IPv4 dependencies in this specification. + +3.7. RFC 2819 Remote Network Monitoring Management Information Base + + There are no IPv4 dependencies in this specification. + +3.8. RFC 3411 An Architecture for Describing SNMP Management Frameworks + + There are no IPv4 dependencies in this specification. + +3.9. RFC 3412 Message Processing and Dispatching for the Simple Network + Management Protocol (SNMP) + + There are no IPv4 dependencies in this specification. + +3.10. RFC 3413 SNMP Applications + + There are no IPv4 dependencies in this specification. + +3.11. RFC 3414 User-based Security Model (USM) for version 3 of the + Simple Network Management Protocol (SNMPv3) + + There are no IPv4 dependencies in this specification. + +3.12. RFC 3415 View-based Access Control Model (VACM) for the Simple + Network Management Protocol (SNMP) + + There are no IPv4 dependencies in this specification. + +3.13. RFC 3416 Protocol Operations for Version 2 of the Simple Network + Management Protocol (SNMP) + + 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. + + + + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 4] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +3.14. RFC 3417 Transport Mappings for Version 2 of the Simple Network + Management Protocol (SNMP) + + Section 2 Definitions contains the following definition: + + 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)) + + Section 8.1, Usage Example, also contains examples which uses IPv4 + address, but it has no significance in the operation of the + specification. + +3.15. RFC 3418 Management Information Base for Version 2 of the Simple + Network Management Protocol (SNMP) + + There are no IPv4 dependencies in this specification. + +4. Draft Standards + + 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. + +4.1. RFC 1493 Definitions of Managed Objects for Bridges + + There are no IPv4 dependencies in this specification. + +4.2. RFC 1559 DECnet Phase IV MIB Extensions + + There are no IPv4 dependencies in this specification. + + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 5] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +4.3. RFC 1657 Definitions of Managed Objects for the Fourth + Version of the Border Gateway Protocol (BGP-4) using SMIv2 + + 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. + +4.4. RFC 1658 Definitions of Managed Objects for Character Stream + Devices using SMIv2 + + There are no IPv4 dependencies in this specification. + +4.5. RFC 1659 Definitions of Managed Objects for RS-232-like Hardware + Devices using SMIv2 + + There are no IPv4 dependencies in this specification. + +4.6. RFC 1660 Definitions of Managed Objects for Parallel-printer-like + Hardware Devices using SMIv2 + + There are no IPv4 dependencies in this specification. + +4.7. RFC 1694 Definitions of Managed Objects for SMDS Interfaces using + SMIv2 + + This MIB module definition defines the following subtree: + + 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. + + -- 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 + + + +Nesser II & Bergstrom Informational [Page 6] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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 ::= + 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 } + + 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 + + + +Nesser II & Bergstrom Informational [Page 7] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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 } + + 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. + +4.8. RFC 1724 RIP Version 2 MIB Extension + + 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. + +4.9. RFC 1748 IEEE 802.5 MIB using SMIv2 + + There are no IPv4 dependencies in this specification. + +4.10. RFC 1850 OSPF Version 2 Management Information Base + + 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. + + + + + + + + +Nesser II & Bergstrom Informational [Page 8] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +4.11. RFC 2115 Management Information Base for Frame Relay DTEs + Using SMIv2 + + 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. + +4.12. RFC 2790 Host Resources MIB + + There are no IPv4 dependencies in this specification. + +4.13. RFC 2863 The Interfaces Group MIB + + 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. + +4.14. RFC 3592 Definitions of Managed Objects for the Synchronous + Optical Network/Synchronous Digital Hierarchy (SONET/SDH) + + There are no IPv4 dependencies in this specification. + +4.15. RFC 3593 Textual Conventions for MIB Modules Using Performance + History Based on 15 Minute Intervals + + There are no IPv4 dependencies in this specification. + +5. Proposed Standards + + 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. + +5.1. RFC 1239 Reassignment of experimental MIBs to standard MIBs + + There are no IPv4 dependencies in this specification. + +5.2. RFC 1269 Definitions of Managed Objects for the Border + Gateway Protocol: Version 3 + + The use of BGP3 has been deprecated and is not discussed. + + + + + +Nesser II & Bergstrom Informational [Page 9] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +5.3. RFC 1285 FDDI Management Information Base + + There are no IPv4 dependencies in this specification. + +5.4. RFC 1381 SNMP MIB Extension for X.25 LAPB + + There are no IPv4 dependencies in this specification. + +5.5. RFC 1382 SNMP MIB Extension for the X.25 Packet Layer + + There are no IPv4 dependencies in this specification. + +5.6. RFC 1414 Identification MIB + + There are no IPv4 dependencies in this specification. + +5.7. RFC 1418 SNMP over OSI + + There are no IPv4 dependencies in this specification. + +5.8. RFC 1419 SNMP over AppleTalk + + There are no IPv4 dependencies in this specification. + +5.9. RFC 1420 SNMP over IPX + + There are no IPv4 dependencies in this specification. + +5.10. RFC 1461 SNMP MIB extension for Multiprotocol Interconnect + over X.25 + + The following objects are defined in Section 4, Definitions: + + 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 + + + +Nesser II & Bergstrom Informational [Page 10] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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. + + 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. + + This value can only be written when the + mioxPeerStatus object with the same + + + +Nesser II & Bergstrom Informational [Page 11] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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. + +5.11. RFC 1471 The Definitions of Managed Objects for the Link + Control Protocol of the Point-to-Point Protocol + + There are no IPv4 dependencies in this specification. + +5.12. RFC 1472 The Definitions of Managed Objects for the Security + Protocols of the Point-to-Point Protocol + + There are no IPv4 dependencies in this specification. + +5.13. RFC 1473 The Definitions of Managed Objects for the IP Network + Control Protocol of the Point-to-Point Protocol + + This MIB module is targeted specifically at IPv4 over PPP. A new MIB + module would need to be defined to support IPv6 over PPP. + +5.14. RFC 1474 The Definitions of Managed Objects for the Bridge + Network Control Protocol of the Point-to-Point Protocol + + There are no IPv4 dependencies in this specification. + +5.15. RFC 1512 FDDI Management Information Base + + There are no IPv4 dependencies in this specification. + +5.16. RFC 1513 Token Ring Extensions to the Remote Network + Monitoring MIB + + There are no IPv4 dependencies in this specification. + +5.17. RFC 1525 Definitions of Managed Objects for Source Routing + Bridges + + There are no IPv4 dependencies in this specification. + + + + +Nesser II & Bergstrom Informational [Page 12] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +5.18. RFC 1628 UPS Management Information Base + + There are no IPv4 dependencies in this specification. + +5.19. RFC 1666 Definitions of Managed Objects for SNA NAUs using SMIv2 + + There are no IPv4 dependencies in this specification. + +5.20. RFC 1696 Modem Management Information Base (MIB) using SMIv2 + + There are no IPv4 dependencies in this specification. + +5.21. RFC 1697 Relational Database Management System (RDBMS) + 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 + + + +Nesser II & Bergstrom Informational [Page 13] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + "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. + + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 14] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +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. + + + +Nesser II & Bergstrom Informational [Page 15] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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. + + + + +Nesser II & Bergstrom Informational [Page 16] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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 + + + +Nesser II & Bergstrom Informational [Page 17] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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." + + + +Nesser II & Bergstrom Informational [Page 18] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + ::= { 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), + + + +Nesser II & Bergstrom Informational [Page 19] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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)) + + + + + +Nesser II & Bergstrom Informational [Page 20] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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. + + + + + + + +Nesser II & Bergstrom Informational [Page 21] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +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. + + + + + +Nesser II & Bergstrom Informational [Page 22] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +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. + + + + + + + + +Nesser II & Bergstrom Informational [Page 23] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +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 } + + + +Nesser II & Bergstrom Informational [Page 24] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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: + + The MIB defined by this memo supports use of both IPv4 and IPv6 + addressing. + + This specification is both IPv4 and IPv6 aware. + +5.62. RFC 2562 Definitions of Protocol and Managed Objects for + TN3270E Response Time Collection Using SMIv2 + + This MIB module inherits IP version-independence by virtue of + importing the appropriate definitions from RFC 2561. + +5.63. RFC 2564 Application Management MIB + + The following textual convention is defined: + + ApplTAddress ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Denotes a transport service address. + + For snmpUDPDomain, an ApplTAddress is 6 octets long, + + + +Nesser II & Bergstrom Informational [Page 25] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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)) + + A new TC should be defined to handle IPv6 addresses. + +5.64. RFC 2584 Definitions of Managed Objects for APPN/HPR in + IP Networks + + 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. + +5.65. RFC 2594 Definitions of Managed Objects for WWW Services + + There are no IPv4 dependencies in this specification. + +5.66. RFC 2605 Directory Server Monitoring MIB + + There are no IPv4 dependencies in this specification. + +5.67. RFC 2613 Remote Network Monitoring MIB Extensions for + Switched Networks Version 1.0 + + There are no IPv4 dependencies in this specification. + +5.68. RFC 2618 RADIUS Authentication Client MIB + + This RFC defines the following objects: + + 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, + + + +Nesser II & Bergstrom Informational [Page 26] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + radiusAuthClientPacketsDropped Counter32 + } + + 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. + +5.69. RFC 2619 RADIUS Authentication Server MIB + + This MIB defines the followings objects: + + 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 } + + This object needs to be deprecated and replaced by one that supports + both IPv4 and IPv6 addresses. + + + + + + +Nesser II & Bergstrom Informational [Page 27] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +5.70. RFC 2622 Routing Policy Specification Language (RPSL) + + The only objects in the version of RPSL that deal with IP addresses + are defined as: + + <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. + + <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. + + 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. + +5.71. RFC 2662 Definitions of Managed Objects for the ADSL Lines + + There are no IPv4 dependencies in this specification. + +5.72. RFC 2667 IP Tunnel MIB + + 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. + + A similar MIB for tunneling over IPv6 should be defined. + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 28] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +5.73. RFC 2669 DOCSIS Cable Device MIB Cable Device Management + Information Base for DOCSIS compliant Cable Modems and + Cable Modem Termination Systems + + 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. + +5.74. RFC 2670 Radio Frequency (RF) Interface Management Information + Base for MCNS/DOCSIS compliant RF interfaces + + This MIB defines the following objects: + +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 } + + This object needs to be deprecated and replaced by one that supports + both IPv4 and IPv6 addresses. + + + +Nesser II & Bergstrom Informational [Page 29] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +5.75. RFC 2674 Definitions of Managed Objects for Bridges with + Traffic Classes, Multicast Filtering and Virtual LAN + Extensions + + There are no IPv4 dependencies in this specification. + +5.76. RFC 2677 Definitions of Managed Objects for the NBMA Next + Hop Resolution Protocol (NHRP) + + There are no IPv4 dependencies in this specification. + +5.77. RFC 2720 Traffic Flow Measurement: Meter MIB + + This specification is both IPv4 and IPv6 aware and needs no changes. + +5.78. RFC 2725 Routing Policy System Security + + There are no IPv4 dependencies in this specification. + +5.79. RFC 2726 PGP Authentication for RIPE Database Updates + + There are no IPv4 dependencies in this specification. + +5.80. RFC 2737 Entity MIB (Version 2) + + There are no IPv4 dependencies in this specification. + +5.81. RFC 2741 Agent Extensibility (AgentX) Protocol Version 1 + + Although the examples in the document are for IPv4 transport only, + there is no IPv4 dependency in the AgentX protocol itself. + +5.82. RFC 2742 Definitions of Managed Objects for Extensible SNMP + Agents + + There are no IPv4 dependencies in this specification. + +5.83. RFC 2748 The COPS (Common Open Policy Service) Protocol + + This specification is both IPv4 and IPv6 aware and needs no changes. + +5.84. RFC 2749 COPS usage for RSVP + + There are no IPv4 dependencies in this specification. + +5.85. RFC 2769 Routing Policy System Replication + + There are no IPv4 dependencies in this specification. + + + +Nesser II & Bergstrom Informational [Page 30] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +5.86. RFC 2787 Definitions of Managed Objects for the Virtual + Router Redundancy Protocol + + 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. + +5.87. RFC 2788 Network Services Monitoring MIB + + There are no IPv4 dependencies in this specification. + +5.88. RFC 2789 Mail Monitoring MIB + + There are no IPv4 dependencies in this specification. + +5.89. RFC 2837 Definitions of Managed Objects for the Fabric Element + in Fibre Channel Standard + + There are no IPv4 dependencies in this specification. + +5.90. RFC 2856 Textual Conventions for Additional High Capacity + Data Types + + There are no IPv4 dependencies in this specification. + +5.91. RFC 2864 The Inverted Stack Table Extension to the Interfaces + Group MIB + + There are no IPv4 dependencies in this specification. + +5.92. RFC 2895 Remote Network Monitoring MIB Protocol Identifier + Reference + + This specification is both IPv4 and IPv6 aware and needs no changes. + +5.93. RFC 2925 Definitions of Managed Objects for Remote + Ping, Traceroute, and Lookup Operations + + This MIB mostly is IPv4 and IPv6 aware. There are a few assumptions + that are problems, though. In the following object definitions: + + pingCtlDataSize OBJECT-TYPE + SYNTAX Unsigned32 (0..65507) + UNITS "octets" + MAX-ACCESS read-create + + + +Nesser II & Bergstrom Informational [Page 31] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + + 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 } + + The DESCRIPTION clauses need to be updated to remove the IPv4 + dependencies. + +5.94. RFC 2932 IPv4 Multicast Routing MIB + + This specification is only defined for IPv4 and a similar MIB must be + defined for IPv6. + +5.95. RFC 2933 Internet Group Management Protocol 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. + + + + + + + +Nesser II & Bergstrom Informational [Page 32] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +5.96. RFC 2940 Definitions of Managed Objects for Common + Open Policy Service (COPS) Protocol Clients + + This MIB is both IPv4 and IPv6 aware and needs no changes. + +5.97. RFC 2954 Definitions of Managed Objects for Frame + Relay Service + + There are no IPv4 dependencies in this specification. + +5.98. RFC 2955 Definitions of Managed Objects for Monitoring + and Controlling the Frame Relay/ATM PVC Service + Interworking Function + + There are no IPv4 dependencies in this specification. + +5.99. RFC 2959 Real-Time Transport Protocol Management Information Base + + There are no IPv4 dependencies in this specification. + +5.100. RFC 2981 Event MIB + + There are no IPv4 dependencies in this specification. + +5.101. RFC 2982 Distributed Management Expression MIB + + There are no IPv4 dependencies in this specification. + +5.102. RFC 3014 Notification Log MIB + + There are no IPv4 dependencies in this specification. + +5.103. RFC 3019 IP Version 6 Management Information Base for + The Multicast Listener Discovery Protocol + + This is an IPv6 related document and is not discussed in this + document. + +5.104. RFC 3020 Definitions of Managed Objects for Monitoring + and Controlling the UNI/NNI Multilink Frame Relay Function + + There are no IPv4 dependencies in this specification. + +5.105. RFC 3055 Management Information Base for the PINT Services + Architecture + + There are no IPv4 dependencies in this specification. + + + + +Nesser II & Bergstrom Informational [Page 33] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +5.106. RFC 3060 Policy Core Information Model -- Version 1 + Specification (CIM) + + There are no IPv4 dependencies in this specification. + +5.107. RFC 3084 COPS Usage for Policy Provisioning (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. + +5.108. RFC 3165 Definitions of Managed Objects for the Delegation of + Management Scripts + + There are no IPv4 dependencies in this specification. + +5.109. RFC 3231 Definitions of Managed Objects for Scheduling + Management Operations + + There are no IPv4 dependencies in this specification. + +5.110. RFC 3291 Textual Conventions for Internet Network Addresses + + There are no IPv4 dependencies in this specification. + +5.111. RFC 3635 Definitions of Managed Objects for the + Ethernet-like Interface Types + + There are no IPv4 dependencies in this specification. + +5.112. RFC 3636 Definitions of Managed Objects for IEEE 802.3 Medium + Attachment Units (MAUs) + + There are no IPv4 dependencies in this specification. + +6. Experimental RFCs + + 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. + +6.1. RFC 1187 Bulk Table Retrieval with the SNMP + + There are no IPv4 dependencies in this specification. + + + +Nesser II & Bergstrom Informational [Page 34] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +6.2. RFC 1224 Techniques for managing asynchronously generated + alerts + + There are no IPv4 dependencies in this specification. + +6.3. RFC 1238 CLNS MIB for use with Connectionless Network Protocol + (ISO 8473) and End System to Intermediate System (ISO 9542) + + There are no IPv4 dependencies in this specification. + +6.4. RFC 1592 Simple Network Management Protocol Distributed Protocol + Interface Version 2.0 + + There are no IPv4 dependencies in this specification. + +6.5. RFC 1792 TCP/IPX Connection Mib Specification + + There are no IPv4 dependencies in this specification. + +6.6. RFC 2724 RTFM: New Attributes for Traffic Flow Measurement + + There are no IPv4 dependencies in this specification. + +6.7. RFC 2758 Definitions of Managed Objects for Service Level + Agreements Performance Monitoring + + This specification is both IPv4 and IPv6 aware and needs no changes. + +6.8. RFC 2786 Diffie-Helman USM Key Management Information Base and + Textual Convention + + There are no IPv4 dependencies in this specification. + +6.9. RFC 2903 Generic AAA Architecture + + There are no IPv4 dependencies in this specification. + +6.10. RFC 2934 Protocol Independent Multicast MIB for IPv4 + + This document is specific to IPv4. + +6.11. RFC 3179 Script MIB Extensibility Protocol Version 1.1 + + There are no IPv4 dependencies in this specification. + + + + + + + +Nesser II & Bergstrom Informational [Page 35] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +7. Summary of Results + + In the initial survey of RFCs, 36 positives were identified out of a + total of 153, broken down as follows: + + 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% + + Of those identified, many require no action because they document + outdated and unused protocols, while others are document protocols + that are actively being updated by the appropriate working groups. + Additionally there are many instances of standards that should be + updated but do not cause any operational impact if they are not + updated. The remaining instances are documented below. + +7.1. Standards + +7.1.1. STD 16, Structure of Management Information (RFCs 1155 and 1212) + + 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. + +7.1.2. STD 17 Simple Network Management Protocol (RFC 1213) + + The limitations identified have been addressed, because RFC 1213 has + been split into multiple modules which are all IPv6 capable. + +7.2. Draft Standards + +7.2.1. BGP4 MIB (RFC 1657) + + This problem is currently being addressed by the Inter Domain Routing + (IDR) WG [2]. + +7.2.2. SMDS MIB (RFC 1694) + + See Internet Area standards. Once a specification for IPv6 over SMDS + is created a new MIB must be defined. + +7.2.3. RIPv2 MIB (RFC 1724) + + There is no updated MIB module to cover the problems outlined. A new + MIB module should be defined. + + + +Nesser II & Bergstrom Informational [Page 36] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +7.2.4. OSPFv2 MIB (RFC 1850) + + This problem is currently being addressed by the OSPF WG [3]. + +7.2.5. Transport MIB (RFC 1906) + + 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. + +7.3. Proposed Standards + +7.3.1. MIB for Multiprotocol Interconnect over X.25 (RFC 1461) + + 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. + +7.3.2. PPP IPCP MIB (RFC 1473) + + There is no updated MIB to cover the problems outlined. A new MIB + should be defined. + +7.3.3. Appletalk MIB (RFC 1742) + + 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. + +7.3.4. The Definitions of Managed Objects for IP Mobility + Support using SMIv2 (RFC 2006) + + The problems are being resolved by the MIP6 WG [4]. + +7.3.5. SMIv2 IP MIB (RFC 2011) + + This issue is being resolved by the IPv6 WG [5]. + +7.3.6. SNMPv2 TCP MIB (RFC 2012) + + This issue is being resolved by the IPv6 WG [6]. + + + + + + +Nesser II & Bergstrom Informational [Page 37] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +7.3.7. SNMPv2 UDP MIB (RFC 2013) + + This issue is being resolved by the IPv6 WG [7]. + +7.3.8. RMON-II MIB (RFC 2021) + + 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. + +7.3.9. DataLink Switching using SMIv2 MIB (RFC 2024) + + The problems have not been addressed and an updated MIB should be + defined. + +7.3.10. IP Forwarding Table MIB (RFC 2096) + + This issue is being worked on by the IPv6 WG [9]. + +7.3.11. Classical IP & ARP over ATM MIB (RFC 2320) + + 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. + +7.3.12. Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) + + 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. + +7.3.13. ATM MIB (RFC 2515) + + 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. + +7.3.14. TN3270 MIB (RFC 2562) + + The problems identified are not being addressed and a new MIB module + may need to be defined. + + + + + +Nesser II & Bergstrom Informational [Page 38] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +7.3.15. Application MIB (RFC 2564) + + 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. + +7.3.16. Definitions of Managed Objects for APPN/HPR in IP Networks + (RFC 2584) + + The problems identified are not addressed and a new MIB may be + defined. + +7.3.17. RADIUS MIB (RFC 2618) + + The problems have not been addressed and a new MIB should be defined. + +7.3.18. RADIUS Authentication Server MIB (RFC 2619) + + The problems have not been addressed and a new MIB should be defined. + +7.3.19. RPSL (RFC 2622) + + Additional objects must be defined for IPv6 addresses and prefixes. + + [10] defines extensions to solve this issue, and it is being + considered for publication. + +7.3.20. IPv4 Tunnel MIB (RFC 2667) + + The issue is being resolved. + +7.3.21. DOCSIS MIB (RFC 2669) + + This problem is currently being addressed by the IPCDN WG. + +7.3.22. RF MIB For DOCSIS (RFC 2670) + + This problem is currently being addressed by the IPCDN WG [11]. + +7.3.23. VRRP MIB (RFC 2787) + + The problems have not been addressed and a new MIB may need to be + defined. + +7.3.24. MIB For Traceroute, Pings and Lookups (RFC 2925) + + The problems have not been addressed and a new MIB may need to be + defined. + + + +Nesser II & Bergstrom Informational [Page 39] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +7.3.25. IPv4 Multicast Routing MIB (RFC 2932) + + The problems have not been addressed a new MIB must be defined. + +7.3.26. IGMP MIB (RFC 2933) + + This problem is currently being addressed by the MAGMA WG [12]. + +7.4. Experimental RFCs + +7.4.1. Protocol Independent Multicast MIB for IPv4 (RFC 2934) + + The problems have not been addressed and a new MIB may need to be + defined. + +8. Security Considerations + + This memo examines the IPv6-readiness of specifications; this does + not have security considerations in itself. + +9. Acknowledgements + + 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. + + 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. + +10. References + +10.1. Normative Reference + + [1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the + Survey of IPv4 Addresses in Currently Deployed IETF Standards", + RFC 3789, June 2004. + + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 40] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +10.2. Informative References + + [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. + + [3] Joyal, D. and V. Manral, "Management Information Base for + OSPFv3", Work in Progress, April 2004. + + [4] Keeni, G., Koide, K., Nagami, K. and S. Gundavelli, "The Mobile + IPv6 MIB", Work in Progress, February 2004. + + [5] Routhier, S., Editor, "Management Information Base for the + Internet Protocol (IP)", Work in Progress, April 2004. + + [6] Raghunarayan, R., Editor, "Management Information Base for the + Transmission Control Protocol (TCP)", Work in Progress, February + 2004. + + [7] Fenner, B. and J. Flick, "Management Information Base for the + User Datagram Protocol (UDP)", Work in Progress, April 2004. + + [8] Waldbusser, S., "Remote Network Monitoring Management + Information Base Version 2 Using SMIv2", Work in Progress, + February 2004. + + [9] Haberman, B., "IP Forwarding Table MIB", Work in Progress, + February 2004. + + [10] Blunk, L., Damas, J., Parent, F. and A. Robachevsky, "Routing + Policy Specification Language next generation (RPSLng)", Work in + Progress, April 2004. + + [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. + + [12] Chesterfield, J., Editor, "Multicast Group Membership Discovery + MIB", Work in Progress, February 2004. + + + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 41] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +11. Authors' Addresses + + 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 + + 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 + + EMail: andreas.bergstrom@hiof.no + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 42] + +RFC 3796 IPv4 in the IETF Operations & Management Area June 2004 + + +12. Full Copyright Statement + + 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. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Nesser II & Bergstrom Informational [Page 43] + |