IP Tunnel MIB
obsoletes
- rfc-2667 — IP Tunnel MIB
Extracted elements (25)
A separate tunnelInetConfigTable (rather than allowing row creation directly in tunnelIfTable indexed by ifIndex) was chosen because ifIndex values are agent-chosen and may change across restarts. Indexing by manager-controlled values (endpoint addresses, encapsulation method, and a manager-chosen ID) avoids interoperability problems and simplifies row creation.
New tunnels over IPv4 or IPv6 should be assigned IANAtunnelType values and reuse the interface type tunnel(131) rather than receiving separate IANAifType values. Previously, non-point-to-point tunnels (e.g., 6to4) could not be expressed in the tunnel MIB and were assigned IANAifType values; RFC 4087 corrects this, deprecating sixToFour(215) IANAifType in favor of sixToFour(11) IANAtunnelType.
The object tunnelIfTOS was not renamed to the more accurate tunnelIfDSCPMethod because the name appeared in RFC 2667 and existing MIB objects cannot be renamed once published.
Every ifEntry representing a tunnel should have ifType set to tunnel(131). An entry in the IP Tunnel MIB exists for every ifEntry with this ifType. Creating a tunnel via SNMP also instantiates rows in ifTable and tunnelIfTable; deleting it removes those rows.
If the combined octet count of tunnelInetConfigLocalAddress and tunnelInetConfigRemoteAddress exceeds 110, OIDs of column instances will exceed the 128 sub-identifier maximum and will be inaccessible via SNMPv1, SNMPv2c, or SNMPv3. In practice, IPv4 and IPv6 addresses do not reach this limit.
The ifRcvAddressTable usage for a tunnel interface is defined by the encapsulation-specific MIB. If unspecified, the default is one entry per tunnel interface whose address is tunnelIfLocalInetAddress.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, SNMPv3 with cryptographic security enabled is RECOMMENDED.
It is RECOMMENDED that implementers consider the security features provided by SNMPv3, including full support for its cryptographic mechanisms for authentication and privacy.
New types of tunnels over IPv4 or IPv6 should not be assigned IANAifType values; they should be assigned IANAtunnelType values and reuse the tunnel(131) interface type.
The tunnelIfTable is a conceptual table indexed by ifIndex containing one entry per configured tunnel, with fields for encapsulation method, hop limit, security, TOS/DSCP, flow label, address type, local/remote inet addresses, and encapsulation limit.
The tunnelInetConfigTable is the current (non-deprecated) configuration table indexed by (addressType, localAddress, remoteAddress, encapsMethod, ID). It supports both IPv4 and IPv6 and can be used for dynamic tunnel creation and mapping endpoints to ifIndex values.
tunnelConfigTable and its associated objects (tunnelConfigLocalAddress, tunnelConfigRemoteAddress, tunnelConfigEncapsMethod, tunnelConfigID, tunnelConfigIfIndex, tunnelConfigStatus) are deprecated IPv4-only objects replaced by tunnelInetConfigTable.
tunnelIfEncapsLimit (Integer32, -1|0..255) limits the maximum number of additional encapsulations permitted at this node, per RFC 2473 section 4.1.1. A value of -1 means no limit beyond packet-size constraints.
tunnelIfEncapsMethod is a read-only IANAtunnelType value identifying the encapsulation method in use (e.g., direct(2), gre(3), l2tp(5), sixToFour(11)). It appears in both tunnelIfTable and as an index component in tunnelInetConfigTable.
tunnelIfFlowLabel (IPv6FlowLabelOrAny) specifies how the IPv6 Flow Label is set in the outer header; a value of -1 invokes a traffic conditioner. This object need not be present when the tunnel is not over IPv6.
tunnelIfHopLimit (Integer32, 0|1..255) specifies the IPv4 TTL or IPv6 Hop Limit placed in the outer IP header; a value of 0 means the value is copied from the payload header.
tunnelIfSecurity is a read-only INTEGER with values none(1), ipsec(2), or other(3), indicating the method used to secure the outer IP header. More specific information may be available in a security-protocol-specific MIB.
tunnelIfTOS (Integer32, -2..63) encodes how the high 6 bits (DSCP) of the outer IP TOS/Traffic Class are set: -1 means copied from payload, -2 means a traffic conditioner is invoked, and 0–63 sets the field directly.
tunnelInetConfigID (Integer32, 1..2147483647) distinguishes multiple tunnels sharing the same endpoints and encapsulation method. For protocols allowing only one tunnel per endpoint pair (e.g., GRE, IP-in-IP), the value is always 1; for protocols like L2F allowing parallel tunnels, managers choose a non-conflicting value.
tunnelInetConfigStorageType (StorageType) controls persistence of a config row. If set to permanent(4), no objects in the row need be writable.
This document introduces the IANAtunnelType textual convention, maintained in the IANAifType-MIB. Initial values include other(1), direct(2), gre(3), minimal(4), l2tp(5), pptp(6), l2f(7), udp(8), atmp(9), msdp(10), sixToFour(11), sixOverFour(12), isatap(13), and teredo(14). Assignment policy mirrors that of IANAifType.
SNMP versions prior to SNMPv3 lack adequate security. Even on an IPsec-secured network, there is no per-principal access control for MIB objects without SNMPv3. Operators must configure SNMP entities to restrict GET/SET access to authorized principals only.
Unauthorized read access to tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, tunnelIfLocalAddress, tunnelIfRemoteAddress, or any object in the tunnelConfigTable or tunnelInetConfigTable would reveal tunnel topology information. GET and NOTIFY access to these objects should be controlled and the values should possibly be encrypted in transit.
Unauthorized write access to writable MIB objects (tunnelIfHopLimit, tunnelIfTOS, tunnelIfAddressType, tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, tunnelInetConfigStatus) could allow unauthorized creation or modification of tunnels, resulting in denial of service or redirection of packets to an arbitrary destination.
tunnelInetConfigEntry is indexed by (tunnelInetConfigAddressType, tunnelInetConfigLocalAddress, tunnelInetConfigRemoteAddress, tunnelInetConfigEncapsMethod, tunnelInetConfigID). If the combined octet length of local and remote addresses exceeds 110, the resulting OIDs exceed the 128 sub-identifier limit and cannot be accessed via SNMPv1, SNMPv2c, or SNMPv3.