RFC 3291 (rfc3291) - Page 3 of 20
Textual Conventions for Internet Network Addresses
Alternative Format: Original Text Document
RFC 3291 TCs for Internet Network Addresses May 2002 The textual conventions defined in this document can also be used to represent generic Internet subnets and Internet address ranges. A generic Internet subnet is represented by three objects, one whose syntax is InetAddressType, a second one whose syntax is InetAddress and a third one whose syntax is InetAddressPrefixLength. The InetAddressType value again determines the concrete format of the InetAddress value while the InetAddressPrefixLength identifies the Internet network address prefix. A generic range of consecutive Internet addresses is represented by three objects. The first one has the syntax InetAddressType while the remaining objects have the syntax InetAddress and specify the start and end of the address range. The InetAddressType value again determines the format of the InetAddress values. 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 MIB modules that only need to represent IPv4 or IPv6 addresses SHOULD use the InetAddressType/InetAddress textual conventions defined in this memo. There are many widely deployed MIB modules that use IPv4 addresses and which need to be revised to support IPv6. These MIBs can be categorized as follows: 1. MIB modules which define management information that is in principle IP version neutral, but the MIB currently uses addressing constructs specific to a certain IP version. 2. MIB modules which define management information that is specific to particular IP version (either IPv4 or IPv6) and which is very unlikely to ever be applicable to another IP version. MIB modules of the first type SHOULD provide object definitions (e.g., tables) that work with all versions of IP. In particular, when revising a MIB module which contains IPv4 specific tables, it is suggested to define new tables using the textual conventions defined in this memo which support all versions of IP. The status of the new tables SHOULD be "current" while the status of the old IP version specific tables SHOULD be changed to "deprecated". The other approach of having multiple similar tables for different IP versions is strongly discouraged. Daniele, et. al. Standards Track
