IP Tunnel MIB
obsoleted by
- rfc-4087 — IP Tunnel MIB
Extracted elements (21)
An additional manager-chosen tunnelConfigID index component is included to support protocols such as L2F that allow multiple parallel tunnels between the same endpoints, enabling the MIB to generalize across both single-tunnel and multi-tunnel encapsulation methods.
Two separate tables (tunnelIfTable and tunnelConfigTable) are used rather than allowing row creation directly in tunnelIfTable. Because ifIndex values are agent-chosen and may change across restarts, a separate config table indexed by manager-controlled values (endpoint addresses, encapsulation method, and an ID) avoids row-creation complications and interoperability problems.
The MIB is SMIv2-compliant; an SMIv1-conforming translation is possible but Counter64 objects would be omitted and some machine-readable information would be converted to textual descriptions, which is not considered a semantic change.
This MIB supports only tunnels over IPv4 networks. Management of tunnels over non-IPv4 networks (including IPv6 networks) is explicitly out of scope and may be handled by other MIBs.
When creating a row for an encapsulation method that allows only one tunnel per endpoint pair, the management station should use tunnelConfigID=1 and set tunnelConfigStatus to createAndGo. For methods like L2F, a pseudo-random ID should be used; if an inconsistentValue error is returned, a new random ID should be selected and retried.
Every row in tunnelIfTable with a fixed destination address MUST have a corresponding row in tunnelConfigTable, regardless of whether the tunnel was created via SNMP.
The agent need not support setting tunnelConfigStatus to createAndWait or notInService, since there are no other writable objects in tunnelConfigTable and writable objects in corresponding tables may be modified while the row is active.
The ifType of a tunnel interface MUST be set to 'tunnel' (131). An entry in the IP Tunnel MIB will exist for every ifEntry with this ifType.
The tunnelMIBBasicGroup is mandatory for compliance. Write access to tunnelIfHopLimit, tunnelIfTOS, and tunnelConfigStatus is not required; implementations may expose these as read-only.
Each tunnel is represented as a logical interface (ifEntry) in the Interfaces MIB with ifType set to 131 ('tunnel'). The ifStack table correlates tunnel interfaces to the underlying physical interfaces on which the local IPv4 addresses are configured.
The IP Tunnel MIB contains two tables: the tunnelIfTable, which holds information on configured tunnels indexed by ifIndex, and the tunnelConfigTable, which supports dynamic tunnel creation and provides a mapping from endpoint addresses to ifIndex values.
tunnelConfigEntry is indexed by the 4-tuple (tunnelConfigLocalAddress, tunnelConfigRemoteAddress, tunnelConfigEncapsMethod, tunnelConfigID) and contains tunnelConfigIfIndex (InterfaceIndexOrZero) and tunnelConfigStatus (RowStatus).
tunnelConfigID is an Integer32 (1..2147483647) used to distinguish multiple tunnels with the same endpoints and encapsulation method. For protocols allowing only one tunnel per endpoint pair (e.g., GRE, IP-in-IP), this value is 1; for protocols like L2F allowing parallel tunnels, the manager chooses a unique ID.
tunnelConfigStatus uses the SMIv2 RowStatus convention to create and delete tunnel rows. Creating a row causes the agent to assign an ifIndex and instantiate corresponding rows in ifTable and tunnelIfTable; deleting a row removes all three corresponding entries.
tunnelIfEncapsMethod enumerates supported encapsulation types: other(1), direct(2) for IP-in-IP with no intermediate header, gre(3), minimal(4) for RFC 2004 Minimal Forwarding Header, l2tp(5), pptp(6), l2f(7), udp(8), and atmp(9).
tunnelIfEntry is indexed by ifIndex and contains fields: tunnelIfLocalAddress (IpAddress), tunnelIfRemoteAddress (IpAddress), tunnelIfEncapsMethod (INTEGER enum), tunnelIfHopLimit (Integer32 0..255), tunnelIfSecurity (INTEGER enum), and tunnelIfTOS (Integer32 -2..63).
tunnelIfHopLimit specifies the TTL placed in the outer IP header; a value of 0 indicates the TTL is copied from the payload packet's header. The field is read-write but write access is not required for compliance.
tunnelIfSecurity indicates the security method applied to the tunnel: none(1), ipsec(2) for IPsec authentication or encryption between endpoints, or other(3). More specific information is available in the security protocol's own MIB.
tunnelIfTOS specifies the high 6 bits of the TOS field in the outer IP header: -1 means copy from payload header, -2 means invoke a traffic conditioner (with details in a traffic conditioner MIB), and 0–63 sets the field to that value directly.
Implementers are recommended to use the SNMPv3 User-based Security Model (RFC 2574) and View-based Access Control Model (RFC 2575) to restrict access to MIB objects only to principals with legitimate rights.
Unauthorized write access to the MIB's read-write and read-create objects (e.g., tunnel creation/deletion/modification) could cause denial of service or unauthorized tunnel manipulation. SNMPv1 is an insecure environment, and SET operations without proper protection can negatively affect network operations.