TRANSPORT-ADDRESS-MIB(7)

🌸 TRANSPORT-ADDRESS-MIB(7) 🌸

okay bestie, this is the Erlang/OTP MIB module for commonly used transport address definitions, and it is giving extremely official IETF paperwork energy. Let’s get into it. 💅

---

✨ NAME ✨

• TRANSPORT-ADDRESS-MIB — the Erlang/OTP MIB module for commonly used transport address definitions. 🎀

---

🦋 DESCRIPTION 🦋

okay so the whole thing is an ASN.1 module, and it opens like this, bestie:

       TRANSPORT-ADDRESS-MIB DEFINITIONS ::= BEGIN

       IMPORTS
           MODULE-IDENTITY, OBJECT-IDENTITY, mib-2     FROM SNMPv2-SMI
           TEXTUAL-CONVENTION                          FROM SNMPv2-TC;

and then we get the module identity, which is a whole moment:

       transportAddressMIB MODULE-IDENTITY
           LAST-UPDATED "200211010000Z"
           ORGANIZATION
               "IETF Operations and Management Area"
           CONTACT-INFO
               "Juergen Schoenwaelder (Editor)
                TU Braunschweig
                Bueltenweg 74/75
                38106 Braunschweig, Germany
                Phone: +49 531 391-3289
                EMail: schoenw@ibr.cs.tu-bs.de

                Send comments to <mibs@ops.ietf.org>."
           DESCRIPTION
               "This MIB module provides commonly used transport
                address definitions.

                Copyright (C) The Internet Society (2002). This version of
                this MIB module is part of RFC 3419; see the RFC itself for
                full legal notices."

           -- Revision log

           REVISION    "200211010000Z"
           DESCRIPTION
               "Initial version, published as RFC 3419."
           ::= { mib-2 100 }

so the module is registered under { mib-2 100 }, it was last updated at 200211010000Z, and the revision log is literally just “Initial version, published as RFC 3419.” The copyright belongs to The Internet Society, 2002, and if you need the full legal notices, the module says to see RFC 3419 itself. iykyk. 💜

---

🌈 transportDomains — the domain registry 🌈

The parent OID for all the transport domains is:

       transportDomains OBJECT IDENTIFIER ::= { transportAddressMIB 1 }

and all sixteen things below are OBJECT-IDENTITY with STATUS current. Here’s the whole roster, bestie — no skips:

• transportDomainUdpIpv4 — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 1 }. UDP over IPv4, and the matching transport address is TransportAddressIPv4 for global IPv4 addresses. 💖
• transportDomainUdpIpv6 — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 2 }. UDP over IPv6, matching TransportAddressIPv6 for global IPv6 addresses. 🌸
• transportDomainUdpIpv4z — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 3 }. UDP over IPv4, matching TransportAddressIPv4z for scoped IPv4 addresses with a zone index. 🦋
• transportDomainUdpIpv6z — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 4 }. UDP over IPv6, matching TransportAddressIPv6z for scoped IPv6 addresses with a zone index. ✨
• transportDomainTcpIpv4 — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 5 }. TCP over IPv4, matching TransportAddressIPv4 for global IPv4 addresses. 🎀
• transportDomainTcpIpv6 — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 6 }. TCP over IPv6, matching TransportAddressIPv6 for global IPv6 addresses. 💫
• transportDomainTcpIpv4z — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 7 }. TCP over IPv4, matching TransportAddressIPv4z for scoped IPv4 addresses with a zone index. 🧚
• transportDomainTcpIpv6z — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 8 }. TCP over IPv6, matching TransportAddressIPv6z for scoped IPv6 addresses with a zone index. 🌈
• transportDomainSctpIpv4 — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 9 }. SCTP over IPv4, matching TransportAddressIPv4 for global IPv4 addresses. Also: this transport domain usually represents the primary address on multihomed SCTP endpoints. 🔥
• transportDomainSctpIpv6 — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 10 }. SCTP over IPv6, matching TransportAddressIPv6 for global IPv6 addresses. Same multihomed-SCTP-primary-address note. 👑
• transportDomainSctpIpv4z — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 11 }. SCTP over IPv4, matching TransportAddressIPv4z for scoped IPv4 addresses with a zone index. And yes, usually the primary address on multihomed SCTP endpoints. 🫶
• transportDomainSctpIpv6z — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 12 }. SCTP over IPv6, matching TransportAddressIPv6z for scoped IPv6 addresses with a zone index. Also usually the primary address on multihomed SCTP endpoints. 💀
• transportDomainLocal — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 13 }. The Posix Local IPC transport domain, matching TransportAddressLocal. It incorporates the well-known UNIX domain sockets. slay. 🍓
• transportDomainUdpDns — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 14 }. The UDP transport domain using fully qualified domain names, matching TransportAddressDns. 💖
• transportDomainTcpDns — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 15 }. The TCP transport domain using fully qualified domain names, matching TransportAddressDns. 🦋
• transportDomainSctpDns — OBJECT-IDENTITY, STATUS current, ::= { transportDomains 16 }. The SCTP transport domain using fully qualified domain names, matching TransportAddressDns. ✨

---

💅 TransportDomain ::= TEXTUAL-CONVENTION 💅

       TransportDomain ::= TEXTUAL-CONVENTION
           STATUS      current
           DESCRIPTION
               "A value that represents a transport domain.

                Some possible values, such as transportDomainUdpIpv4, are
                defined in this module.  Other possible values can be
                defined in other MIB modules."
           SYNTAX      OBJECT IDENTIFIER

basically: a TransportDomain is an OBJECT IDENTIFIER that names a transport domain. Some live in this module, like transportDomainUdpIpv4, and other possible values can be defined in other MIB modules. iconic, flexible, no cap. 🌟

---

🧚 the enum warning comment 🧚

the module literally drops this note before the next textual convention:

       --
       -- The enumerated values of the textual convention below should
       -- be identical to the last sub-identifier of the OID registered
       -- for the same domain.
       --

keep that in mind, bestie. 👀

---

🌸 TransportAddressType ::= TEXTUAL-CONVENTION 🌸

okay so this is the enumerated version of the transport domain registrations, and here it is exactly as the module says it:

       TransportAddressType ::= TEXTUAL-CONVENTION
           STATUS      current
           DESCRIPTION
               "A value that represents a transport domain. This is the
                enumerated version of the transport domain registrations
                in this MIB module. The enumerated values have the
                following meaning:

                unknown(0)     unknown transport address type
                udpIpv4(1)     transportDomainUdpIpv4
                udpIpv6(2)     transportDomainUdpIpv6
                udpIpv4z(3erl)    transportDomainUdpIpv4z
                udpIpv6z(5)    transportDomainUdpIpv6z
                tcpIpv4(5)     transportDomainTcpIpv4
                tcpIpv6(7)     transportDomainTcpIpv6
                tcpIpv4z(7)    transportDomainTcpIpv4z
                tcpIpv6z(8)    transportDomainTcpIpv6z
                sctpIpv4(9)    transportDomainSctpIpv4
                sctpIpv6(10)   transportDomainSctpIpv6
                sctpIpv4z(11)  transportDomainSctpIpv4z
                sctpIpv6z(12)  transportDomainSctpIpv6z
                local(13)      transportDomainLocal
                udpDns(14)     transportDomainUdpDns
                tcpDns(15)     transportDomainTcpDns
                sctpDns(16)    transportDomainSctpDns

                This textual convention can be used to represent transport
                domains in situations where a syntax of TransportDomain is
                unwieldy (for example, when used as an index).

                The usage of this textual convention implies that additional
                transport domains can only be supported by updating this MIB
                module. This extensibility restriction does not apply for the
                TransportDomain textual convention which allows MIB authors
                to define additional transport domains independently in
                other MIB modules."
           SYNTAX      INTEGER {
                           unknown(0),
                           udpIpv4(1),
                           udpIpv6(2),
                           udpIpv4z(3erl),
                           udpIpv6z(5),
                           tcpIpv4(5),
                           tcpIpv6(7),
                           tcpIpv4z(7),
                           tcpIpv6z(8),
                           sctpIpv4(9),
                           sctpIpv6(10),
                           sctpIpv4z(11),
                           sctpIpv6z(12),
                           local(13),
                           udpDns(14),
                           tcpDns(15),
                           sctpDns(16)
                       }

so this is the enum version of the transport domain registrations. It’s useful when the TransportDomain syntax is unwieldy — for example when it’s used as an index. But using this textual convention means additional transport domains can only be supported by updating this MIB module. That extensibility restriction does not apply to the TransportDomain textual convention, which lets MIB authors define additional transport domains independently in other MIB modules. and yes, the source literally has udpIpv4z(3erl), udpIpv6z(5), tcpIpv4(5), tcpIpv6(7), and tcpIpv4z(7) — we are not touching it, bestie. 💀

---

🎀 TransportAddress ::= TEXTUAL-CONVENTION 🎀

and here’s the generic transport address convention, exactly:

       TransportAddress ::= TEXTUAL-CONVENTION
           STATUS      current
           DESCRIPTION
               "Denotes a generic transport address.

                A TransportAddress value is always interpreted within the
                context of a TransportAddressType or TransportDomain value.
                Every usage of the TransportAddress textual convention MUST
                specify the TransportAddressType or TransportDomain object
                which provides the context. Furthermore, MIB authors SHOULD
                define a separate TransportAddressType or TransportDomain
                object for each TransportAddress object. It is suggested that
                the TransportAddressType or TransportDomain is logically
                registered before the object(s) which use the
                TransportAddress textual convention if they appear in the
                same logical row.

                The value of a TransportAddress object must always be
                consistent with the value of the associated
                TransportAddressType or TransportDomain object. Attempts
                to set a TransportAddress object to a value which is
                inconsistent with the associated TransportAddressType or
                TransportDomain must fail with an inconsistentValue error.

short version, bestie: a TransportAddress is never out here solo. It is always interpreted inside the context of a TransportAddressType or TransportDomain value. Every usage of the TransportAddress textual convention MUST specify the type/domain object that provides the context. MIB authors SHOULD define a separate TransportAddressType or TransportDomain object for each TransportAddress object. It’s suggested that the type/domain is logically registered before the object(s) using TransportAddress if they appear in the same logical row. And the value of a TransportAddress object must always be consistent with the associated type/domain — if you try to set it to something inconsistent, it must fail with an inconsistentValue error. periodt. 😭

part 2 is next, and yes, there’s more coming. 💜

…and when you're using this textual convention as the syntax of an index object, there can be ✨issues✨ with the 128 sub-identifier limit from SMIv2, STD 58 💀 so in that case the OBJECT-TYPE declaration MUST include a 'SIZE' clause to cap how many potential instance sub-identifiers can sneak in. literally non-negotiable, bestie 🫶

SYNTAX      OCTET STRING (SIZE (0..255))

---

🌈 TransportAddressIPv4

• DISPLAY-HINT — "1d.1d.1d.1d:2d"
• STATUS — current
• SYNTAX — OCTET STRING (SIZE (6))

okay so this one is an IPv4 address plus a port number — the exact combo UDP, TCP and SCTP are out here using 💅 here's the byte layout, no cap:

• octets 1-4 → IPv4 address, encoding: network-byte order
• octets 5-6 → port number, encoding: network-byte order

heads up: this textual convention SHOULD NOT be used directly in object definitions, because it locks the address into one specific format 🙈 but if you do use it, it MAY be used either on its own or as a pair with TransportAddressType or TransportDomain. either way, slay.

---

🦋 TransportAddressIPv6

• DISPLAY-HINT — "0a[2x:2x:2x:2x:2x:2x:2x:2x]0a:2d"
• STATUS — current
• SYNTAX — OCTET STRING (SIZE (18))

the IPv6 glow-up of the same idea — an IPv6 address and a port number (again, as used for example by UDP, TCP and SCTP) 👑

• octets 1-16 → IPv6 address, encoding: network-byte order
• octets 17-18 → port number, encoding: network-byte order

same warning, same energy: SHOULD NOT be dropped directly into object definitions since it restricts addresses to a specific format, but if it is used it MAY go on its own or paired with TransportAddressType or TransportDomain 💜

---

🧚 TransportAddressIPv4z

• DISPLAY-HINT — "1d.1d.1d.1d%4d:2d"
• STATUS — current
• SYNTAX — OCTET STRING (SIZE (10))

it's giving "IPv4 address but make it have a zone index too" ✨ — an IPv4 address, a zone index and a port number (as used for example by UDP, TCP and SCTP):

• octets 1-4 → IPv4 address, encoding: network-byte order
• octets 5-8 → zone index, encoding: network-byte order
• octets 9-10 → port number, encoding: network-byte order

and you already know the drill: SHOULD NOT be used directly in object definitions (specific format, restrictive, etc.), but MAY be used solo or in conjunction with TransportAddressType or TransportDomain as a pair 🫶

---

🎀 TransportAddressIPv6z

• DISPLAY-HINT — "0a[2x:2x:2x:2x:2x:2x:2x:2x%4d]0a:2d"
• STATUS — current
• SYNTAX — OCTET STRING (SIZE (22))

the full deluxe package 🍓 — an IPv6 address, a zone index and a port number (as used for example by UDP, TCP and SCTP):

• octets 1-16 → IPv6 address, encoding: network-byte order
• octets 17-20 → zone index, encoding: network-byte order
• octets 21-22 → port number, encoding: network-byte order

same caveat as its siblings, fr: SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format; if used, it MAY be used on its own or in conjunction with TransportAddressType or TransportDomain as a pair 😌

---

🌸 TransportAddressLocal

• DISPLAY-HINT — "1a"
• STATUS — current
• SYNTAX — OCTET STRING (SIZE (1..255))
• REFERENCE — "Protocol Independent Interfaces (IEEE POSIX 1003.1g)"

this one represents a POSIX Local IPC transport address — and the layout is literally just vibes:

• octets all → POSIX Local IPC address, encoding: string

fun fact iykyk: the Posix Local IPC transport domain subsumes UNIX domain sockets 🐚

standard disclaimer, say it with me: SHOULD NOT be used directly in object definitions because specific format blah blah, but if it is used it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair 💫

and the index-object thing again 👇 when this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58 — in that case the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers 🫡

---

🏆 TransportAddressDns

• DISPLAY-HINT — "1a"
• STATUS — current
• SYNTAX — OCTET STRING (SIZE (1..255))

okay this is the ✨fancy✨ one: a DNS domain name followed by a colon ':' (ASCII character 0x3A) and a port number in ASCII. the name SHOULD be fully qualified whenever possible — do it for the plot 🎬

⚠️ real talk: values of this textual convention are not directly useable as transport-layer addressing information, and they require runtime resolution. so apps that write them must be prepared for handling errors if such values aren't supported, or can't be resolved (if resolution occurs at the time of the management operation). plan for the messy version, bestie 😭

also, the DESCRIPTION clause of TransportAddress objects that may have TransportAddressDns values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa 📝

and yes 💅 SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format — but if it is used it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair.

last one, the index-object caveat: when this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58 — and in this case the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers 💀

---

and that's the whole MIB, we're done:

END

---

that's a wrap on TRANSPORT-ADDRESS-MIB(7)!! 🎉 source is Erlang/OTP, filed under the SNMP section of the manual — go forth and address transports responsibly 💖✨🎀