rfc-3419

Textual Conventions for Transport Addresses

M. Daniele, J. Schoenwaelder
date2002-12 streamLegacy statusPROPOSED STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc3419 doi10.17487/RFC3419
This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS-TRACK]

Extracted elements (27)

design-rationale §3

DISPLAY-HINTs for the address textual conventions are aligned with the formats used in URIs (RFC 2396, RFC 3291) to provide consistent human-readable representations across management and non-management contexts.

snmp

design-rationale §3.1.2

SNMPv2-TM transport domain values were originally for SNMP-only use but were later applied to non-SNMP endpoints and are incomplete (lacking IPv6 support). This memo defines protocol-independent transport domain values to fill that gap.

snmp

design-rationale §3.1.1

TransportAddress uses SIZE (0..255) rather than SIZE (1..255) as in TAddress, to allow representation of unknown transport addresses. The sub-type TransportAddress (SIZE (1..255)) is intentionally identical to TAddress for backward compatibility.

snmp

design-rationale §3

TransportAddressIPv4z and TransportAddressIPv6z are provided to support scoped Internet addresses that include a zone index, required on devices connecting multiple zones where addresses are not necessarily unique across zones.

ip, snmp

design-rationale §3

Two mechanisms for adding new transport domains are provided: updating this MIB module (which also updates the TransportAddressType enumeration) or defining new OIDs in other MIB modules (which cannot extend TransportAddressType). MIB designers choose between compact/limited-extensibility or verbose/fully-extensible approaches.

snmp, registry

interoperability-note §3.1.1

Existing MIB modules may be updated to use the definitions in this memo by replacing TDomain with TransportDomain and TAddress with TransportAddress (SIZE (1..255)), preserving full semantic equivalence.

snmp

interoperability-note §3.1.2

Programs that interpret transport domain values should accept both the SNMPv2-TM domain values (for SNMP-specific endpoints) and the domain values defined in this memo, to provide interoperability in cases where distinguishing the protocol running over a transport endpoint is not possible or desirable.

snmp

normative-requirement §4 MUST

Attempts to set a TransportAddress object to a value inconsistent with the associated TransportAddressType or TransportDomain must fail with an inconsistentValue error.

snmp

normative-requirement §4 MUST

Every usage of the TransportAddress textual convention MUST specify the TransportAddressType or TransportDomain object that provides the context for interpreting the address value.

snmp

normative-requirement §3 SHOULD

MIB authors SHOULD define a separate TransportDomain or TransportAddressType object for each TransportAddress object to support arbitrary combinations of scoped Internet transport addresses.

snmp

normative-requirement §3.1.1 SHOULD

New MIB modules SHOULD use the generic TransportDomain, TransportAddressType, and TransportAddress definitions from this memo rather than TDomain/TAddress from SNMPv2-TC.

snmp

normative-requirement §3.1.2 SHOULD

SNMP transport endpoints SHOULD continue to use definitions from the SNMPv2-TM MIB module where applicable, and SHOULD use the transport domain values from this memo for SNMP transports not defined in SNMPv2-TM (e.g., SNMP over UDP over IPv6).

snmp

normative-requirement §4 SHOULD NOT

The specific address-format textual conventions (TransportAddressIPv4, TransportAddressIPv6, etc.) SHOULD NOT be used directly in object definitions since they restrict addresses to a specific format; when used, they MAY be used alone or with TransportAddressType/TransportDomain.

snmp

normative-requirement §3.1.2 SHOULD

Transport domain values from this memo SHOULD be used for all transport endpoints not carrying SNMP traffic; programs interpreting transport domain values should also accept SNMPv2-TM domain values for interoperability with existing implementations.

snmp

normative-requirement §4 SHOULD

TransportAddressDns names SHOULD be fully qualified whenever possible; objects using this convention must fully describe in their DESCRIPTION clause how and when names are resolved to IP addresses.

dns, snmp

normative-requirement §4 MUST

When TransportAddress (or TransportAddressLocal or TransportAddressDns) is used as the syntax of an index object, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers, due to the SMIv2 limit of 128 sub-identifiers.

snmp

protocol-element §4

TransportAddress is a generic transport address textual convention with SYNTAX OCTET STRING (SIZE (0..255)). Its value is always interpreted within the context of an associated TransportAddressType or TransportDomain object.

snmp

protocol-element §4

TransportAddressType is an enumerated INTEGER textual convention representing the well-known transport domains: unknown(0), udpIpv4(1) through sctpDns(16). It provides a compact, index-friendly alternative to TransportDomain but cannot be extended outside this MIB module.

snmp, registry

protocol-element §4

TransportDomain is a textual convention with SYNTAX OBJECT IDENTIFIER that represents a transport domain. Values such as transportDomainUdpIpv4 are defined in this module; additional values may be defined in other MIB modules, making it fully extensible.

snmp, registry

registry §4

This document registers 16 transport domain OIDs under transportDomains (transportAddressMIB 1): transportDomainUdpIpv4(1) through transportDomainSctpDns(16), covering UDP, TCP, and SCTP over IPv4, IPv6, scoped IPv4z/IPv6z, POSIX Local IPC, and DNS-based addressing.

registry, snmp

security-consideration §6

This MIB module defines only textual conventions, not concrete management objects. Because meaningful security considerations apply only to modules that define management objects, this document has no direct security impact on the Internet.

security, snmp

wire-format §4

TransportAddressDns encodes a DNS domain name followed by a colon ':' (0x3A) and an ASCII port number as an OCTET STRING (SIZE 1..255). Values require runtime resolution and are not directly usable as transport-layer addressing information.

dns, snmp

wire-format §4

TransportAddressIPv4 encodes an IPv4 transport address as a 6-octet string: octets 1-4 carry the IPv4 address in network-byte order, octets 5-6 carry the port number in network-byte order. DISPLAY-HINT is '1d.1d.1d.1d:2d'.

ip, snmp

wire-format §4

TransportAddressIPv4z encodes a scoped IPv4 transport address as a 10-octet string: octets 1-4 IPv4 address, 5-8 zone index, 9-10 port number, all in network-byte order. Used with transportDomainUdpIpv4z, transportDomainTcpIpv4z, or transportDomainSctpIpv4z.

ip, snmp

wire-format §4

TransportAddressIPv6 encodes an IPv6 transport address as an 18-octet string: octets 1-16 carry the IPv6 address in network-byte order, octets 17-18 carry the port number in network-byte order. DISPLAY-HINT is '0a[2x:2x:2x:2x:2x:2x:2x:2x]0a:2d'.

ip, snmp

wire-format §4

TransportAddressIPv6z encodes a scoped IPv6 transport address as a 22-octet string: octets 1-16 IPv6 address, 17-20 zone index, 21-22 port number, all in network-byte order. DISPLAY-HINT is '0a[2x:2x:2x:2x:2x:2x:2x:2x%4d]0a:2d'.

ip, snmp

wire-format §4

TransportAddressLocal encodes a POSIX Local IPC (UNIX domain socket) address as an OCTET STRING (SIZE 1..255) with DISPLAY-HINT '1a', carrying the socket path as a string.

snmp