Multicast Address Allocation MIB
Extracted elements (26)
IANAscopeSource and IANAmallocRangeSource textual conventions are defined in a separate IANA-MALLOC-MIB module rather than inline in this document so that IANA can add new values without requiring a new version of RFC 3559. This pattern decouples the protocol MIB lifecycle from the enumeration lifecycle.
The MIB is split into protocol-independent objects (applicable to all multicast address allocation servers and clients, including those allocating source-specific multicast addresses) and protocol-specific objects (MADCAP). This separation allows the protocol-independent tables to be reused if additional allocation protocols are defined in the future.
Scope entries in mallocScopeTable may be dynamically discovered via MZAP (RFC 2776) or statically configured. The mallocScopeSource field (type IANAscopeSource) records how each entry was learned, enabling management systems to distinguish protocol-discovered scopes from operator-configured ones.
The madcapServerGroup is conditional in compliance statements: it is mandatory only for servers that implement the MADCAP client-server protocol. Similarly, madcapClientGroup is mandatory only for clients implementing MADCAP. This allows implementations of other allocation protocols to conform to the MIB without supporting MADCAP objects.
Address ranges for different rows in the mallocAllocRangeTable must be disjoint and must be contained within the address range of the corresponding mallocScopeTable row. Deleting an allocation range has the side effect of deleting any mallocAddressTable entries within that range.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Implementers SHOULD consider using SNMPv3 with full cryptographic mechanisms (authentication and privacy). It is RECOMMENDED to enable cryptographic security and restrict access to only principals with legitimate rights to GET or SET objects.
Each entry in the mallocAddressTable must fall within a range corresponding to an entry in the mallocAllocRangeTable, and mallocAddressRequestId must match the value of mallocRequestId for some entry in the mallocRequestTable.
If mallocScopeDivisible is true, the server must not allocate addresses out of the entire scope range; it may only allocate from a subrange learned via another method. Creating or deleting a non-divisible scope has the side effect of creating or deleting the corresponding mallocAllocRangeTable entry; deleting a divisible scope deletes any corresponding allocation range and request entries.
mallocRequestScopeFirstAddress must match mallocScopeFirstAddress for some row in the mallocScopeTable, ensuring that every request references a known scope.
MADCAP configuration scalars include: madcapConfigExtraAllocationTime (extra time on each side of a lease for clock skew), madcapConfigNoResponseDelay (client wait time for a server response), madcapConfigOfferHold (server hold time after an OFFER before a REQUEST is expected), madcapConfigResponseCacheInterval (0–300 s duplicate-detection window), and madcapConfigClockSkewAllowance (threshold for Excessive Clock Skew errors).
MADCAP counter objects (all Counter32, read-only) track: total errors, requests denied, invalid requests, excessive clock skews, bad lease IDs, and message counts for DISCOVER, INFORM, REQUEST, RENEW, and RELEASE messages received by the server.
Six compliance statements are defined: mallocServerReadOnlyCompliance, mallocClientReadOnlyCompliance, mallocPrefixCoordinatorReadOnlyCompliance (monitoring-only, no write access), and mallocServerFullCompliance, mallocClientFullCompliance, mallocPrefixCoordinatorFullCompliance (full read-create support). Read-only compliance requires all writable objects to be accessible at MIN-ACCESS read-only.
The MALLOC-MIB defines two primary object groups: protocol-independent objects (mallocCapabilities scalar plus five tables for scopes, scope names, allocation ranges, requests, and allocated addresses) applicable to all multicast address allocation servers and clients, and MADCAP-specific objects (configuration and statistics scalars).
The mallocAddressTable records blocks of allocated multicast addresses, indexed by (mallocAddressAddressType, mallocAddressFirstAddress). Each entry carries mallocAddressNumAddrs (block size) and mallocAddressRequestId (foreign key into mallocRequestTable), enabling the query 'who allocated address A?'.
The mallocAllocRangeAdvertisable object (TruthValue) controls whether an allocation range is eligible to be advertised to other MAASs. Its default on row creation is true if the scope is divisible, false otherwise. When true, mallocAllocRangeTotalAllocatedAddrs and mallocAllocRangeTotalRequestedAddrs (populated by a Prefix Coordinator) must be present.
The mallocAllocRangeTable contains subranges from which a MAAS may allocate addresses. It carries Gauge32 counters for currently allocated, offered, waiting, and trying addresses, plus Gauge32 totals (totalAllocatedAddrs, totalRequestedAddrs) populated by a Prefix Coordinator for advertisable ranges. All ranges must be disjoint and contained within the parent mallocScopeTable range.
The mallocCapabilities object is a BITS scalar with three flags: startTime(0) indicates support for future-start-time allocations, serverMobility(1) indicates allocations can be renewed or released from a server other than the one granting the original allocation, and retryAfter(2) indicates support for a waiting state where the client may check back later.
The mallocRequestLeaseIdentifier field is an OCTET STRING (0–255 bytes) holding the Lease Identifier from MADCAP. If the allocation mechanism does not use Lease Identifiers, the value is a zero-length string.
The mallocScopeNameTable extends the scope table with per-language scope names, indexed by (mallocScopeAddressType, mallocScopeFirstAddress, IMPLIED mallocScopeNameLangName). The language tag uses RFC 3066 syntax; mallocScopeNameDefault indicates a preferred fallback name when the desired language is unavailable.
The mallocScopeTable is a conceptual table indexed by mallocScopeAddressType and mallocScopeFirstAddress. Each row describes a multicast scope with fields for first/last address, hop limit, status (RowStatus), source (IANAscopeSource), divisibility, server address, SSM indicator, and storage type. Ranges for different rows must be disjoint.
This document imports IANAscopeSource and IANAmallocRangeSource textual conventions from the IANA-MALLOC-MIB. IANA administers these conventions; new values may be added without reissuing this document. The MALLOC-MIB itself is registered at { mib-2 101 }.
If MADCAP servers are configured to allow renewal or release solely on the basis of the Lease Identifier, unauthorized read access to mallocRequestLeaseIdentifier (a readable object) can enable a denial-of-service attack by allowing an attacker to release or hijack active allocations.
Unauthorized write access to madcapConfigExtraAllocationTime and madcapConfigOfferHold can cause reservations to last too long, potentially causing denial of service when allocation ranges are small. Unauthorized modification of madcapConfigNoResponseDelay can prevent a client from completing multicast address allocation.
Unauthorized write access to mallocScopeNameTable can cause incorrect or misleading scope names to be presented to users, potentially causing applications to use the wrong scope for their data traffic.
Unauthorized write access to mallocScopeTable and mallocAllocRangeTable can cause denial of service (inability to allocate addresses, exhausting address space, overlapping with other organizations' allocations) or cause applications to use a hop limit that wastes bandwidth.
The mallocRequestState object defines four states for an allocation request: allocated(1) — one or more address entries exist in mallocAddressTable; offered(2) — addresses tentatively offered to client but not committed (e.g., via MADCAP OFFER); waiting(3) — allocation blocked while server acquires more space; trying(4) — allocation in progress but no addresses yet offered.