INET-ADDRESS-MIB(7)

💖 INET-ADDRESS-MIB(7) 💖

okay so this is the manual page for INET-ADDRESS-MIB — the Erlang/OTP MIB module, and it's filed under section MIB of the manual. buckle up bestie, it's a whole ASN.1 situation and we're gonna get through it together 🫶

---

🌸 NAME 🌸

INET-ADDRESS-MIB — the Erlang/OTP MIB module for textual conventions for representing Internet addresses. that's it, that's the whole name section, iconic and concise ✨

---

🦋 DESCRIPTION 🦋

so the whole thing literally opens with a module definition, no warmup, no "hey girl", just straight into it. here's the top of the module, verbatim, don't touch the formatting:

INET-ADDRESS-MIB DEFINITIONS ::= BEGIN

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

then we get the module identity block. this is the part that tells you who made this, when, and what it actually is:

inetAddressMIB MODULE-IDENTITY
    LAST-UPDATED "200502040000Z"
    ORGANIZATION
        "IETF Operations and Management Area"
    CONTACT-INFO
        "Juergen Schoenwaelder (Editor)
         International University Bremen
         P.O. Box 750 561
         28725 Bremen, Germany

         Phone: +49 421 200-3587
         EMail: j.schoenwaelder@iu-bremen.de

         Send comments to <ietfmibs@ops.ietf.org>."
    DESCRIPTION
        "This MIB module defines textual conventions for
         representing Internet addresses.  An Internet
         address can be an IPv4 address, an IPv6 address,
         or a DNS domain name.  This module also defines
         textual conventions for Internet port numbers,
         autonomous system numbers, and the length of an
         Internet address prefix.

         Copyright (C) The Internet Society (2005).  This version
         of this MIB module is part of RFC 4001, see the RFC
         itself for full legal notices."
    REVISION     "200502040000Z"
    DESCRIPTION
        "Third version, published as RFC 4001.  This revision
         introduces the InetZoneIndex, InetScopeType, and
         InetVersion textual conventions."
    REVISION     "200205090000Z"
    DESCRIPTION
        "Second version, published as RFC 3291.  This
         revision contains several clarifications and
         introduces several new textual conventions:
         InetAddressPrefixLength, InetPortNumber,
         InetAutonomousSystemNumber, InetAddressIPv4z,
         and InetAddressIPv6z."
    REVISION     "200006080000Z"
    DESCRIPTION
        "Initial version, published as RFC 2851."
    ::= { mib-2 76 }

so yeah: this module is registered as { mib-2 76 }, the copyright belongs to The Internet Society (2005), this exact version is part of RFC 4001, and if you want the full legal notices you go read the RFC itself. the revision history is a whole glow-up timeline: first version was RFC 2851 on 200006080000Z, second version was RFC 3291 on 200205090000Z (that one added clarifications plus InetAddressPrefixLength, InetPortNumber, InetAutonomousSystemNumber, InetAddressIPv4z and InetAddressIPv6z), and the third version is RFC 4001 on 200502040000Z which introduced InetZoneIndex, InetScopeType and InetVersion. genuinely a character arc 💅

---

💜 InetAddressType 💜

STATUS current — it's current bestie, it's valid, we love that for it.

this one is the vibe check of the whole module: a value that represents a type of Internet address. here's the breakdown, no cap:

• unknown(0) — an unknown address type. this one is a hard MUST: you use it if the value of the corresponding InetAddress object is a zero-length string. it may also be used to indicate an IP address that isn't in one of the formats defined below 👀
• ipv4(1) — an IPv4 address as defined by the InetAddressIPv4 textual convention.
• ipv6(2) — an IPv6 address as defined by the InetAddressIPv6 textual convention.
• ipv4z(3erl) — a non-global IPv4 address including a zone index, as defined by the InetAddressIPv4z textual convention. (yes, it really says 3erl in there. we don't ask questions, we copy it exactly 🫶)
• ipv6z(5) — a non-global IPv6 address including a zone index, as defined by the InetAddressIPv6z textual convention.
• dns(16) — a DNS domain name as defined by the InetAddressDNS textual convention. notice how 3 and 4 are just… skipped. iconic of them honestly.

the rules, and they're fr fr rules:

• every definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
• to support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. it MAY be sub-typed in compliance statements, though, so you can require only a subset of these address types for a compliant implementation.
• implementations must ensure that InetAddressType objects and any dependent objects (like InetAddress objects) are consistent. an inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. and specifically: InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). they're a package deal, a duo, main characters who cannot be separated 😭

and the syntax:

SYNTAX       INTEGER {
                 unknown(0),
                 ipv4(1),
                 ipv6(2),
                 ipv4z(3erl),
                 ipv6z(5),
                 dns(16)
             }

---

🎀 InetAddress 🎀

STATUS current — slay.

denotes a generic Internet address. the whole point:

• an InetAddress value is always interpreted within the context of an InetAddressType value. every single usage of the InetAddress textual convention is required to specify the InetAddressType object that provides that context. it's suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. like, put the label first, then the thing.
• the value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. no exceptions, no vibes-based workarounds 💀
• > ⚠️ 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 this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there's no single DESCRIPTION clause that's appropriate. (SMIv2, STD 58 — remember those two, they come up again.)

syntax:

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

---

🌈 InetAddressIPv4 🌈

DISPLAY-HINT "1d.1d.1d.1d", STATUS current

represents an IPv4 network address:

   Octets   Contents         Encoding
    1-4     IPv4 address     network-byte order

the corresponding InetAddressType value is ipv4(1).

this textual convention SHOULD NOT be used directly in object definitions, because it restricts addresses to a specific format. however, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair. the option is there, it's just not the рекоменд— okay sorry, it's just not the recommended first move 😅

SYNTAX       OCTET STRING (SIZE (4))

---

🦋 InetAddressIPv6 🦋

DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x", STATUS current

represents an IPv6 network address:

   Octets   Contents         Encoding
    1-16    IPv6 address     network-byte order

the corresponding InetAddressType value is ipv6(2).

same deal as the v4 one: 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 InetAddressType, as a pair 🫶

SYNTAX       OCTET STRING (SIZE (16))

---

⭐ InetAddressIPv4z ⭐

DISPLAY-HINT "1d.1d.1d.1d%4d", STATUS current

represents a non-global IPv4 network address, together with its zone index. two things at once, she's multitasking:

   Octets   Contents         Encoding
    1-4     IPv4 address     network-byte order
    5-8     zone index       network-byte order

the corresponding InetAddressType value is ipv4z(3erl).

so about that zone index (bytes 5-8): it's used to disambiguate identical address values on nodes that have interfaces attached to different zones of the same scope. and it may contain the special value 0, which refers to the default zone for each scope. love a default 💅

and yeah — this textual convention SHOULD NOT be used directly in object definitions, because it restricts addresses to a specific format. however, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair.

SYNTAX       OCTET STRING (SIZE (8))

---

🍓 InetAddressIPv6z 🍓

DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d", STATUS current

represents a non-global IPv6 network address, together with its zone index:

   Octets   Contents         Encoding
    1-16    IPv6 address     network-byte order
   17-20    zone index       network-byte order

the corresponding InetAddressType value is ipv6z(5).

the zone index (bytes 17-20) is used to disambiguate identical address values on nodes that have interfaces attached to different zones of the same scope. the zone index may contain the special value 0, which refers to the default zone for each scope. yes it's the same story as the v4z one, just long. it's giving consistency, we stan ✨

the usual caveat: SHOULD NOT be used directly in object definitions, because it restricts addresses to a specific format. however, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair.

SYNTAX       OCTET STRING (SIZE (20))

---

🧚 InetAddressDNS 🧚

DISPLAY-HINT "255a", STATUS current

represents a DNS domain name. the name SHOULD be fully qualified whenever possible. (fully qualified = the whole thing, no shortcuts, no crumbs left behind.)

the corresponding InetAddressType is dns(16).

and this part matters, so pay attention bestie: the DESCRIPTION clause of InetAddress objects that may have InetAddressDNS values MUST fully describe how (and when) these names are to be resolved to IP addresses. like, the whole resolution story has to be documented. no vibes.

also, the resolution of an InetAddressDNS value may require querying multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). the order of the resolution process and which DNS record takes precedence depends on the configuration of the resolver. so it's config-dependent, it's not a fixed rule, don't come for me 🙈

and yes, the familiar disclaimer: this textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. however, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair.

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

---

okay that's not the end, don't close the tab — there's more of this page coming 💅

🌸 InetAddressPrefixLength 🌸

InetAddressPrefixLength ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS       current
    SYNTAX       Unsigned32 (0..2040)

Okay so this one denotes the length of a generic Internet network address prefix. Like, a value of n means "the IP address mask that has n contiguous 1-bits starting from the most significant bit (MSB), and every other bit is 0." That's it, that's the whole vibe ✨

An InetAddressPrefixLength value is always read in the context of an InetAddressType value — literally every usage of this textual convention is required to name the InetAddressType object that provides that context. And hey, the page suggests the InetAddressType object be logically registered before the object(s) that use InetAddressPrefixLength, if they show up in the same logical row. Order matters, bestie 🫶

And what if the value is too big? Any InetAddressPrefixLength value larger than the max length of an IP address for a given InetAddressType gets treated as the maximum significant value for that type:

• 32 for 'ipv4(1)' and 'ipv4z(3erl)'
• 128 for 'ipv6(2)' and 'ipv6z(5)'
• the maximum significant value for 'dns(16)' is 0

Zero is object-specific — it has to be defined as part of the description of whatever object uses this syntax. Examples of what zero might mean: the Internet network address prefix is unknown, or it just doesn't apply 🙈

And the upper bound of the prefix length was chosen to be consistent with the maximum size of an InetAddress. Iconic consistency behavior 💅

---

🎀 InetPortNumber 🎀

InetPortNumber ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS       current
    REFERENCE    "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"
    SYNTAX       Unsigned32 (0..65535)

Represents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA, and a current list of all assignments is available from <http://www.iana.org/> — go look, it's lowkey fascinating 🌐

Zero is object-specific again (same deal as above, it must be defined as part of the description of any object using this syntax). Examples of zero usage: the port number is unknown, or zero is used as a wildcard in a filter 🦋

Reference, not me forgetting: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960.

---

🧚 InetAutonomousSystemNumber 🧚

InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS       current
    REFERENCE    "RFC 1771, RFC 1930"
    SYNTAX       Unsigned32

This one represents an autonomous system number that identifies an Autonomous System (AS). And what's an AS? It's "a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes'." Yes, that trailing apostrophe is in the original and I'm not touching it 😭

IANA maintains the AS number space and has delegated large parts to the regional registries 👑

AS numbers are currently limited to 16 bits (0..65535) — but there's work in progress to enlarge the autonomous system number space to 32 bits! So this textual convention uses an Unsigned32 value without a range restriction, specifically so it can support a larger autonomous system number space. Forward thinking, we love to see it ⭐

Reference: RFC 1771, RFC 1930.

---

🔥 InetScopeType 🔥

InetScopeType ::= TEXTUAL-CONVENTION
    STATUS       current
    SYNTAX       INTEGER {
                     -- reserved(0),
                     interfaceLocal(1),
                     linkLocal(2),
                     subnetLocal(3erl),
                     adminLocal(5),
                     siteLocal(5), -- site-local unicast addresses
                                   -- have been deprecated by RFC 3879
                     -- unassigned(7),
                     -- unassigned(7),
                     -- unassigned(9),
                     -- unassigned(10),
                     -- unassigned(11),
                     -- unassigned(12),
                     -- unassigned(13),
                     global(14)
                     -- reserved(15)
                 }

💀 Reproducing that INTEGER block exactly as it appears on the page — the repeated 5, the 3erl, the doubled -- unassigned(7) comment, all of it. Not my choices, I'm just the messenger, so don't come for me.

So this represents a scope type. It's handy in cases where a MIB has to represent different scope types and there's no context info — like an InetAddress object — that implicitly defines the scope type for you.

<hothotpink>Heads up:</hothotpink> not all possible values have been assigned yet, but they may be assigned in future revisions of this specification. So applications should therefore be able to deal with values not yet assigned — be flexible, bestie 🦋

Reference: RFC 3513.

---

🌈 InetZoneIndex 🌈

InetZoneIndex ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS       current
    REFERENCE    "RFC4007"
    SYNTAX       Unsigned32

A zone index identifies an instance of a zone of a specific scope. Simple as that ✨

The zone index MUST disambiguate identical address values — no two identical address values getting mushed together, periodt. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured 👑

The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index isn't known — e.g. when a management application has to write a link-local IPv6 address without knowing the interface index value. But the default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known. Don't be lazy, iykyk 🙈

Reference: RFC4007.

---

⭐ InetVersion ⭐

InetVersion ::= TEXTUAL-CONVENTION
    STATUS       current
    REFERENCE    "RFC 791, RFC 2460"
    SYNTAX       INTEGER {
                     unknown(0),
                     ipv4(1),
                     ipv6(2)
                 }

A value representing a version of the IP protocol. The three moods:

• unknown(0) — an unknown or unspecified version of the IP protocol.
• ipv4(1) — the IPv4 protocol as defined in RFC 791 (STD 5).
• ipv6(2) — the IPv6 protocol as defined in RFC 2460.

💜 And important: this textual convention SHOULD NOT be used to distinguish different address types associated with IP protocols. InetAddressType was literally designed for that purpose, so put it down and use the right one 🎀

Reference: RFC 791, RFC 2460.

---

END

And that's the whole MIB, bestie — you ate that 🍓✨

She's from the Erlang/OTP SNMP collection, and this page is INET-ADDRESS-MIB(7) — now go forth and address things responsibly 💅👑