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.
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.
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.
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.
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.
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
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
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.
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.
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
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
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.
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)