RFC 2851 (rfc2851) - Page 2 of 16


Textual Conventions for Internet Network Addresses



Alternative Format: Original Text Document



RFC 2851           TCs for Internet Network Addresses          June 2000


   8.  Intellectual Property Notice . . . . . . . . . . . . . . . . 12
       References . . . . . . . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
       Full Copyright Statement . . . . . . . . . . . . . . . . . . 16

1. Introduction

   Several standard-track MIB modules use the IpAddress SMIv2 base type.
   This limits the applicability of these MIB modules to IP Version 4
   (IPv4) since the IpAddress SMIv2 base type can only contain 4 byte
   IPv4 addresses. The IpAddress SMIv2 base type has become problematic
   with the introduction of IP Version 6 (IPv6) addresses [21].

   This document defines multiple textual conventions as a mechanism to
   express generic Internet network layer addresses within MIB module
   specifications. The solution is compatible with SMIv2 (STD 58) and
   SMIv1 (STD 16). New MIB definitions which need to express network
   layer Internet addresses SHOULD use the textual conventions defined
   in this memo. New MIBs SHOULD NOT use the SMIv2 IpAddress base type
   anymore.

   A generic Internet address consists of two objects, one whose syntax
   is InetAddressType, and another whose syntax is InetAddress. The
   value of the first object determines how the value of the second
   object is encoded. The InetAddress textual convention represents an
   opaque Internet address value. The InetAddressType enumeration is
   used to "cast" the InetAddress value into a concrete textual
   convention for the address type. This usage of multiple textual
   conventions allows expression of the display characteristics of each
   address type and makes the set of defined Internet address types
   extensible.

   The textual conventions defined in this document can be used to
   define Internet addresses by using DNS domain names in addition to
   IPv4 and IPv6 addresses. A MIB designer can write compliance
   statements to express that only a subset of the possible address
   types must be supported by a compliant implementation.

   MIB developers who need to represent Internet addresses SHOULD use
   these definitions whenever applicable, as opposed to defining their
   own constructs. Even MIBs that only need to represent IPv4 or IPv6
   addresses SHOULD use the textual conventions defined in this memo.

   In order to make existing widely-deployed IPv4-only MIBs fit for
   IPv6, it might be a valid approach to define separate tables for
   different address types. This is a decision for the MIB designer.
   For example, the tcpConnTable of the TCP-MIB [18] was left intact




Daniele, et al.             Standards Track