RFC 4087
IP Tunnel MIB
RFC 4087: IP Tunnel MIB 🎀
okay bestie, this is RFC 4087, and it's giving full MIB energy ✨ It's written by D. Thaler from Microsoft and published in June 2005 as a Standards Track doc from the Network Working Group. It obsoletes RFC 2667 💅
Status of This Memo 📜
ok so this one is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 for the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 🔍 and distribution of this memo is unlimited, so share away 🦋
Copyright Notice 💜
Copyright (C) The Internet Society (2005). Legal stuff, but it's cute 🌸
Abstract 🧚
so this memo defines a Management Information Base (MIB) module for network management protocols in the Internet community 🌈 it's all about managing tunnels of any type over IPv4 and IPv6 networks 🔥 extension MIB modules can manage protocol-specific objects, and they can also manage security-specific objects 💖 this MIB module doesn't cover tunnels over non-IP networks, but other MIB modules might handle those 🍓 and fun fact, this memo obsoletes RFC 2667 ✨
1. Introduction 🌸
okay so over the last few years the IETF has specified a whole bunch of "tunneling" protocols (check [RFC1241] if you want the early history and examples) 📚 this doc describes the MIB module used to manage tunnels of any type over IPv4 and IPv6 networks 🚇 that includes Generic Routing Encapsulation (GRE) [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal Encapsulation [RFC2004], Layer 2 Tunneling Protocol (L2TP) [RFC2661], Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2 Forwarding (L2F) [RFC2341], UDP (e.g., [RFC1234]), Ascend Tunnel Management Protocol (ATMP) [RFC2107], and IPv6-in-IPv4 [RFC2893] tunnels, plus a few others 🎀
extension MIB modules can manage protocol-specific objects 🦋 they can also manage security-specific objects (e.g., IPsec [RFC2401]) and traffic conditioner [RFC2474] objects 💅
2. The Internet-Standard Management Framework 👑
if you want the full tea on the current Internet-Standard Management Framework, go read section 7 of RFC 3410 [RFC3410] 📖
managed objects live in a virtual information store called the Management Information Base, or MIB 🗂️ you usually reach them through the Simple Network Management Protocol (SNMP) 📡 MIB objects are defined using the mechanisms in the Structure of Management Information (SMI) 🧠 this memo specifies a MIB module that complies with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 🔥
3. Overview 🌈
this MIB module has two current tables and one deprecated table 🍓 the current ones are:
- the Tunnel Interface Table, which holds info on the tunnels a router knows about 🚇
- the Tunnel Inet Config Table, which can dynamically create tunnels and also maps endpoint addresses to the current interface index value 🧚
the version of this MIB module that showed up in RFC 2667 had the Tunnel Config Table, which mapped IPv4 endpoint addresses to interface indexes 🙈 it's deprecated now in favor of the Tunnel Inet Config Table 💀
3.1. Relationship to the Interfaces MIB 🔗
this section explains how this MIB module relates to the Interfaces MIB [RFC2863] 💖 a few areas of correlation get covered in the subsections below 🫶 implementors should check out the Interfaces MIB document to get the general intent of those areas 📚
3.1.1. Layering Model 🍰
each logical interface (physical or virtual) has an ifEntry in the Interfaces MIB [RFC2863] 🌸 tunnels work by creating a logical interface (ifEntry) for each tunnel 🚇 those then get correlated, using the ifStack table of the Interfaces MIB, to the interfaces where the tunnels' local IPv4 or IPv6 addresses are configured 🔗 the basic model looks something like this (for example):
| | | | | |
+--+ +---+ +--+ +---+ | |
|IP-in-IP| | GRE | | |
| tunnel | | tunnel | | |
+--+ +---+ +--+ +---+ | |
| | | | | | <== attachment to underlying
+--+ +---------+ +----------+ +--+ interfaces, to be provided
| Physical interface | by ifStack table
+--------------------------------+3.1.2. ifRcvAddressTable 🦋
the ifRcvAddressTable can be defined in the MIB modules that define the encapsulation below the network layer 💅 it holds the local IP addresses where decapsulation happens 🌈 for example, if IP-in-IP encapsulation is in use, IP-in-IP can define the ifRcvAddressTable 🍓 if it isn't specified, the default is one entry for the tunnel interface, where ifRcvAddressAddress holds the local IP address used for encapsulation/decapsulation (i.e., tunnelIfLocalInetAddress in the Tunnel Interface Table) ✨
3.1.3. ifEntry 🧚
IfEntries are defined in the MIB modules that define the encapsulation below the network layer 🎀 for example, if IP-in-IP encapsulation [20] is in use, IP-in-IP defines the ifEntry 💖
the ifType of a tunnel should be set to "tunnel" (131) 🫶 there's an entry in the IP Tunnel MIB module for every ifEntry with this ifType 🌸 an implementation of the IP Tunnel MIB module may let you create ifEntries through the tunnelConfigTable 🔥 when you create a tunnel, you also get an entry in the ifTable and in the tunnelIfTable, and deleting a tunnel deletes the entry in the ifTable and the tunnelIfTable too 💅
this two-table setup was a big design decision 👑 traditionally, ifIndex values get picked by agents and can change across restarts 🙈 letting rows get created straight in the Tunnel Interface Table, indexed by ifIndex, would make row creation more complicated and/or cause interoperability problems (if each agent had special restrictions on ifIndex) 💀 so instead there's a separate table that's indexed only by things the manager controls 🌈 those are the tunnel endpoint addresses and the encapsulation protocol 🍓 finally, an extra manager-chosen ID goes in the index to support protocols like L2F that allow multiple tunnels between the same endpoints 🧚
4. Definitions 💜
the MIB module itself is below 🪄
TUNNEL-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, transmission,
Integer32, IpAddress FROM SNMPv2-SMI -- [RFC2578]
RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE,
OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
InetAddressType,
InetAddress FROM INET-ADDRESS-MIB -- [RFC4001]
IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB -- [RFC3595]
ifIndex,
InterfaceIndexOrZero FROM IF-MIB -- [RFC2863]
IANAtunnelType FROM IANAifType-MIB; -- [IFTYPE]
tunnelMIB MODULE-IDENTITY
LAST-UPDATED "200505160000Z" -- May 16, 2005
ORGANIZATION "IETF IP Version 6 (IPv6) Working Group"
CONTACT-INFO
" Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: dthaler@microsoft.com"
DESCRIPTION
"The MIB module for management of IP Tunnels,
independent of the specific encapsulation scheme in
use.
Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 4087; see
the RFC itself for full legal notices."
REVISION "200505160000Z" -- May 16, 2005
DESCRIPTION
"IPv4-specific objects were deprecated, including
tunnelIfLocalAddress, tunnelIfRemoteAddress, the
tunnelConfigTable, and the tunnelMIBBasicGroup.
Added IP version-agnostic objects that should be used
instead, including tunnelIfAddressType,
tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress,
the tunnelInetConfigTable, and the
tunnelIMIBInetGroup.
The new tunnelIfLocalInetAddress and
tunnelIfRemoteInetAddress objects are read-write,
rather than read-only.
Updated DESCRIPTION clauses of existing version-
agnostic objects (e.g., tunnelIfTOS) that contained
IPv4-specific text to cover IPv6 as well.
Added tunnelIfFlowLabel for tunnels over IPv6.
The encapsulation method was previously an INTEGER
type, and is now an IANA-maintained textual
convention.
Published as RFC 4087."
REVISION "199908241200Z" -- August 24, 1999
DESCRIPTION
"Initial version, published as RFC 2667."
::= { transmission 131 }
tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 }
tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 }
-- the IP Tunnel MIB-Group
--
-- a collection of objects providing information about
-- IP Tunnels
tunnelIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table containing information on
configured tunnels."
::= { tunnel 1 }
tunnelIfEntry OBJECT-TYPE
SYNTAX TunnelIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel."
INDEX { ifIndex }
::= { tunnelIfTable 1 }
TunnelIfEntry ::= SEQUENCE {
tunnelIfLocalAddress IpAddress, -- deprecated
tunnelIfRemoteAddress IpAddress, -- deprecated
tunnelIfEncapsMethod IANAtunnelType,
tunnelIfHopLimit Integer32,
tunnelIfSecurity INTEGER,
tunnelIfTOS Integer32,
tunnelIfFlowLabel IPv6FlowLabelOrAny,
tunnelIfAddressType InetAddressType,
tunnelIfLocalInetAddress InetAddress,
tunnelIfRemoteInetAddress InetAddress,
tunnelIfEncapsLimit Integer32
}
tunnelIfLocalAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The address of the local endpoint of the tunnel
(i.e., the source address used in the outer IP
header), or 0.0.0.0 if unknown or if the tunnel is
over IPv6.
Since this object does not support IPv6, it is
deprecated in favor of tunnelIfLocalInetAddress."
::= { tunnelIfEntry 1 }okay so we're still in the Definitions section, and the tunnel objects are about to get very deprecated-core 💅 first up is the remote address for the tunnel's tunnelIfEntry:
tunnelIfRemoteAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The address of the remote endpoint of the tunnel
(i.e., the destination address used in the outer IP
header), or 0.0.0.0 if unknown, or an IPv6 address, or
the tunnel is not a point-to-point link (e.g., if it
is a 6to4 tunnel).
Since this object does not support IPv6, it is
deprecated in favor of tunnelIfRemoteInetAddress."
::= { tunnelIfEntry 2 }ngl this one is giving "I was great once, but I've been replaced" 🥀 it's read-only, it's deprecated, and it can't handle IPv6, so the newer tunnelIfRemoteInetAddress is the one to use now 🦋
Next is the encapsulation method, which is the simple, no-drama one. It's read-only and current, and it tells you which encapsulation method the tunnel is using 🎀
tunnelIfEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel."
::= { tunnelIfEntry 3 }Now the hop limit, which is giving main character energy 👑 It's read-write, and the value is the IPv4 TTL or the IPv6 Hop Limit that goes in the outer IP header. The fun part is that 0 doesn't mean "zero," it means "copy it from the payload's header" 🙈
tunnelIfHopLimit OBJECT-TYPE
SYNTAX Integer32 (0 | 1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IPv4 TTL or IPv6 Hop Limit to use in the outer IP
header. A value of 0 indicates that the value is
copied from the payload's header."
::= { tunnelIfEntry 4 }Security is next, and it's a little enum situation 🔥 none(1) means no security, ipsec(2) means IPsec is in use between the tunnel endpoints for authentication, encryption, or both, and other(3) covers everything else. If you want the nitty-gritty, go look in a MIB module for whatever security protocol is actually running 🧚
tunnelIfSecurity OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no security
ipsec(2), -- IPsec security
other(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The method used by the tunnel to secure the outer IP
header. The value ipsec indicates that IPsec is used
between the tunnel endpoints for authentication or
encryption or both. More specific security-related
information may be available in a MIB module for the
security protocol in use."
::= { tunnelIfEntry 5 }Okay the TOS object is a whole mood 🌈 It controls the high 6 bits, which is the differentiated services codepoint, of the IPv4 TOS or IPv6 Traffic Class in the outer header. The special values are -1 (copy the bits from the payload), -2 (a traffic conditioner gets invoked), and 0 through 63 (set the field to that exact number). Also, the object name is a little awkward. The author admits tunnelIfDSCPMethod would've been a better name, but since tunnelIfTOS already showed up in RFC 2667 and existing objects can't be renamed, we're stuck with it 😭
tunnelIfTOS OBJECT-TYPE
SYNTAX Integer32 (-2..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The method used to set the high 6 bits (the
differentiated services codepoint) of the IPv4 TOS or
IPv6 Traffic Class in the outer IP header. A value of
-1 indicates that the bits are copied from the
payload's header. A value of -2 indicates that a
traffic conditioner is invoked and more information
may be available in a traffic conditioner MIB module.
A value between 0 and 63 inclusive indicates that the
bit field is set to the indicated value.
Note: instead of the name tunnelIfTOS, a better name
would have been tunnelIfDSCPMethod, but the existing
name appeared in RFC 2667 and existing objects cannot
be renamed."
::= { tunnelIfEntry 6 }Flow label time 🧚♀️ This is the IPv6 Flow Label setting. It's allowed to be missing in rows where the tunnel isn't running over IPv6. A value of -1 means a traffic conditioner is involved, and anything else just sets the Flow Label field to that value.
tunnelIfFlowLabel OBJECT-TYPE
SYNTAX IPv6FlowLabelOrAny
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The method used to set the IPv6 Flow Label value.
This object need not be present in rows where
tunnelIfAddressType indicates the tunnel is not over
IPv6. A value of -1 indicates that a traffic
conditioner is invoked and more information may be
available in a traffic conditioner MIB. Any other
value indicates that the Flow Label field is set to
the indicated value."
::= { tunnelIfEntry 7 }The address type is the object that tells you what kind of address the local and remote address objects are holding. Read-write and current, no notes 💖
tunnelIfAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The type of address in the corresponding
tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress
objects."
::= { tunnelIfEntry 8 }Local address, the source address in the outer IP header 🫶 If it's unknown, the value is 0.0.0.0 for IPv4 or :: for IPv6, and the type comes from tunnelIfAddressType.
tunnelIfLocalInetAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The address of the local endpoint of the tunnel
(i.e., the source address used in the outer IP
header). If the address is unknown, the value is
0.0.0.0 for IPv4 or :: for IPv6. The type of this
object is given by tunnelIfAddressType."
::= { tunnelIfEntry 9 }And the remote one, the destination address in the outer header, which is the newer, IPv6-friendly version of tunnelIfRemoteAddress from earlier 🦋 If the address is unknown, or the tunnel isn't point-to-point (6to4 is the example), it's 0.0.0.0 for IPv4 tunnels or :: for IPv6 tunnels.
tunnelIfRemoteInetAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The address of the remote endpoint of the tunnel
(i.e., the destination address used in the outer IP
header). If the address is unknown or the tunnel is
not a point-to-point link (e.g., if it is a 6to4
tunnel), the value is 0.0.0.0 for tunnels over IPv4 or
:: for tunnels over IPv6. The type of this object is
given by tunnelIfAddressType."
::= { tunnelIfEntry 10 }Last one on the interface entry: the encapsulation limit 🍓 It's the maximum number of extra encapsulations allowed for packets being encapsulated at this node. A value of -1 means there's no limit, except whatever the packet size already imposes. The reference is RFC 2473, section 4.1.1.
tunnelIfEncapsLimit OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of additional encapsulations
permitted for packets undergoing encapsulation at this
node. A value of -1 indicates that no limit is
present (except as a result of the packet size)."
REFERENCE "RFC 2473, section 4.1.1"
::= { tunnelIfEntry 11 }Now we're moving on to the config side 🎀 tunnelConfigTable is the (conceptual) table of configured tunnels. It maps a set of tunnel endpoints to an ifIndex value, and it's also used for row creation. The big rule is that every row in tunnelIfTable with a fixed IPv4 destination address needs a matching row here, no matter whether it was created over SNMP or not. It's deprecated too, in favor of tunnelInetConfigTable, since IPv6 isn't supported.
tunnelConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelConfigEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The (conceptual) table containing information on
configured tunnels. This table can be used to map a
set of tunnel endpoints to the associated ifIndex
value. It can also be used for row creation. Note
that every row in the tunnelIfTable with a fixed IPv4
destination address should have a corresponding row in
the tunnelConfigTable, regardless of whether it was
created via SNMP.
Since this table does not support IPv6, it is
deprecated in favor of tunnelInetConfigTable."
::= { tunnel 2 }The entry for that table is also deprecated, and it's indexed by four things: the local address, the remote address, the encapsulation method, and the tunnel ID 🧚
tunnelConfigEntry OBJECT-TYPE
SYNTAX TunnelConfigEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel.
Since this entry does not support IPv6, it is
deprecated in favor of tunnelInetConfigEntry."
INDEX { tunnelConfigLocalAddress,
tunnelConfigRemoteAddress,
tunnelConfigEncapsMethod,
tunnelConfigID }
::= { tunnelConfigTable 1 }
TunnelConfigEntry ::= SEQUENCE {
tunnelConfigLocalAddress IpAddress,
tunnelConfigRemoteAddress IpAddress,
tunnelConfigEncapsMethod IANAtunnelType,
tunnelConfigID Integer32,
tunnelConfigIfIndex InterfaceIndexOrZero,
tunnelConfigStatus RowStatus
}The config local address is the local endpoint of the tunnel, or 0.0.0.0 if the device can pick any of its addresses when the tunnel is set up. Deprecated, with the same IPv6 story as before 🥀
tunnelConfigLocalAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The address of the local endpoint of the tunnel, or
0.0.0.0 if the device is free to choose any of its
addresses at tunnel establishment time.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigLocalAddress."
::= { tunnelConfigEntry 1 }The config remote address is the remote endpoint of the tunnel. That's the whole description, and it's deprecated for the IPv6 reason 💅
tunnelConfigRemoteAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The address of the remote endpoint of the tunnel.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigRemoteAddress."
::= { tunnelConfigEntry 2 }Encapsulation method in the config table is the same idea as before: the encapsulation method the tunnel uses, deprecated in favor of tunnelInetConfigEncapsMethod 🌸
tunnelConfigEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The encapsulation method used by the tunnel.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigEncapsMethod."
::= { tunnelConfigEntry 3 }tunnelConfigID is the tiebreaker 🫠 It tells apart multiple tunnels that share the same encapsulation method and endpoints. If the encapsulation only allows one tunnel per pair of endpoints (GRE and IP-in-IP are the examples), the value is 1. For encapsulations that allow parallel tunnels (L2F is the example), the manager picks an ID that doesn't clash with an existing row, and a random number works fine. It's deprecated, so tunnelInetConfigID is the one to use now.
tunnelConfigID OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An identifier used to distinguish between multiple
tunnels of the same encapsulation method, with the
same endpoints. If the encapsulation protocol only
allows one tunnel per set of endpoint addresses (such
as for GRE or IP-in-IP), the value of this object is
1. For encapsulation methods (such as L2F) which
allow multiple parallel tunnels, the manager is
responsible for choosing any ID which does not
conflict with an existing row, such as choosing a
random number.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigID."
::= { tunnelConfigEntry 4 }The config interface index is the ifIndex for the tunnel interface, but only when the row status is active. If it's 0, that's illegal in the active state and just means the index hasn't been assigned yet. Yep, deprecated, yep, tunnelInetConfigIfIndex is the replacement 🎀
tunnelConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"If the value of tunnelConfigStatus for this row is
active, then this object contains the value of ifIndex
corresponding to the tunnel interface. A value of 0
is not legal in the active state, and means that the
interface index has not yet been assigned.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigIfIndex."
::= { tunnelConfigEntry 5 }Last object in this batch is the row status, which is how you create or delete rows in this table 🌈 The agent doesn't have to support createAndWait or notInService, since nothing else in this table is writable. Meanwhile, writable objects in matching rows of tables like tunnelIfTable can still change while the row is active.
Creating a row for an encapsulation method that doesn't allow parallel tunnels is simple: use a tunnelConfigID of 1 and set tunnelConfigStatus to createAndGo. For methods like L2F that allow parallel tunnels, the management station can pick a pseudo-random number for the ID, again with createAndGo. If that ID is already taken and the set operation returns inconsistentValue, the station should just pick another pseudo-random number and try again 🔁
tunnelConfigStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The status of this row, by which new entries may be
created, or old entries deleted from this table. The
agent need not support setting this object to
createAndWait or notInService since there are no other
writable objects in this table, and writable objects
in rows of corresponding tables such as the
tunnelIfTable may be modified while this row is
active.
To create a row in this table for an encapsulation
method which does not support multiple parallel
tunnels with the same endpoints, the management
station should simply use a tunnelConfigID of 1, and
set tunnelConfigStatus to createAndGo. For
encapsulation methods such as L2F which allow multiple
parallel tunnels, the management station may select a
pseudo-random number to use as the tunnelConfigID and
set tunnelConfigStatus to createAndGo. In the event
that this ID is already in use and an
inconsistentValue is returned in response to the set
operation, the management station should simply select
a new pseudo-random number and retry the operation."
::= { tunnelConfigEntry 6 } Creating a row in this table will cause an interface
index to be assigned by the agent in an
implementation-dependent manner, and corresponding
rows will be instantiated in the ifTable and the
tunnelIfTable. The status of this row will become
active as soon as the agent assigns the interface
index, regardless of whether the interface is
operationally up.
Deleting a row in this table will likewise delete the
corresponding row in the ifTable and in the
tunnelIfTable.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigStatus."
::= { tunnelConfigEntry 6 }
tunnelInetConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelInetConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table containing information on
configured tunnels. This table can be used to map a
set of tunnel endpoints to the associated ifIndex
value. It can also be used for row creation. Note
that every row in the tunnelIfTable with a fixed
destination address should have a corresponding row in
the tunnelInetConfigTable, regardless of whether it
was created via SNMP."
::= { tunnel 3 }
tunnelInetConfigEntry OBJECT-TYPE
SYNTAX TunnelInetConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel. Note that there is
a 128 subid maximum for object OIDs. Implementers
need to be aware that if the total number of octets in
tunnelInetConfigLocalAddress and
tunnelInetConfigRemoteAddress exceeds 110 then OIDs of
column instances in this table will have more than 128
sub-identifiers and cannot be accessed using SNMPv1,
SNMPv2c, or SNMPv3. In practice this is not expected
to be a problem since IPv4 and IPv6 addresses will not
cause the limit to be reached, but if other types are
supported by an agent, care must be taken to ensure
that the sum of the lengths do not cause the limit to
be exceeded."
INDEX { tunnelInetConfigAddressType,
tunnelInetConfigLocalAddress,
tunnelInetConfigRemoteAddress,
tunnelInetConfigEncapsMethod,
tunnelInetConfigID }
::= { tunnelInetConfigTable 1 }okay so next up is the row itself, the big SEQUENCE that lists every column one by one 💅
TunnelInetConfigEntry ::= SEQUENCE {
tunnelInetConfigAddressType InetAddressType,
tunnelInetConfigLocalAddress InetAddress,
tunnelInetConfigRemoteAddress InetAddress,
tunnelInetConfigEncapsMethod IANAtunnelType,
tunnelInetConfigID Integer32,
tunnelInetConfigIfIndex InterfaceIndexOrZero,
tunnelInetConfigStatus RowStatus,
tunnelInetConfigStorageType StorageType
}
tunnelInetConfigAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type over which the tunnel encapsulates
packets."
::= { tunnelInetConfigEntry 1 }
tunnelInetConfigLocalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address of the local endpoint of the tunnel, or
0.0.0.0 (for IPv4) or :: (for IPv6) if the device is
free to choose any of its addresses at tunnel
establishment time."
::= { tunnelInetConfigEntry 2 }
tunnelInetConfigRemoteAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address of the remote endpoint of the tunnel."
::= { tunnelInetConfigEntry 3 }
tunnelInetConfigEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel."
::= { tunnelInetConfigEntry 4 }
tunnelInetConfigID OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An identifier used to distinguish between multiple
tunnels of the same encapsulation method, with the
same endpoints. If the encapsulation protocol only
allows one tunnel per set of endpoint addresses (such
as for GRE or IP-in-IP), the value of this object is
1. For encapsulation methods (such as L2F) which
allow multiple parallel tunnels, the manager is
responsible for choosing any ID which does not
conflict with an existing row, such as choosing a
random number."
::= { tunnelInetConfigEntry 5 }
tunnelInetConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the value of tunnelInetConfigStatus for this row
is active, then this object contains the value of
ifIndex corresponding to the tunnel interface. A
value of 0 is not legal in the active state, and means
that the interface index has not yet been assigned."
::= { tunnelInetConfigEntry 6 }
tunnelInetConfigStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row, by which new entries may be
created, or old entries deleted from this table. The
agent need not support setting this object to
createAndWait or notInService since there are no other
writable objects in this table, and writable objects
in rows of corresponding tables such as the
tunnelIfTable may be modified while this row is
active.
To create a row in this table for an encapsulation
method which does not support multiple parallel
tunnels with the same endpoints, the management
station should simply use a tunnelInetConfigID of 1,
and set tunnelInetConfigStatus to createAndGo. For
encapsulation methods such as L2F which allow multiple
parallel tunnels, the management station may select a
pseudo-random number to use as the tunnelInetConfigID
and set tunnelInetConfigStatus to createAndGo. In the
event that this ID is already in use and an
inconsistentValue is returned in response to the set
operation, the management station should simply select
a new pseudo-random number and retry the operation.
Creating a row in this table will cause an interface
index to be assigned by the agent in an
implementation-dependent manner, and corresponding
rows will be instantiated in the ifTable and the
tunnelIfTable. The status of this row will become
active as soon as the agent assigns the interface
index, regardless of whether the interface is
operationally up.
Deleting a row in this table will likewise delete the
corresponding row in the ifTable and in the
tunnelIfTable."
::= { tunnelInetConfigEntry 7 }
tunnelInetConfigStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type of this row. If the row is
permanent(4), no objects in the row need be writable."
::= { tunnelInetConfigEntry 8 }now the conformance bits 🎀 these say which groups a device has to implement to count as compliant, plus the compliance statements themselves
-- conformance information
tunnelMIBConformance
OBJECT IDENTIFIER ::= { tunnelMIB 2 }
tunnelMIBCompliances
OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 }
tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 }
-- compliance statements
tunnelMIBCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The (deprecated) IPv4-only compliance statement for
the IP Tunnel MIB.
This is deprecated in favor of
tunnelMIBInetFullCompliance and
tunnelMIBInetReadOnlyCompliance."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBBasicGroup }
OBJECT tunnelIfHopLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfTOS
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelConfigStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { tunnelMIBCompliances 1 }
tunnelMIBInetFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The full compliance statement for the IP Tunnel MIB."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBInetGroup }
OBJECT tunnelIfAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2),
ipv4z(3), ipv6z(4) }
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation only needs to
support the addresses it actually supports on the
device."
::= { tunnelMIBCompliances 2 }and last but not least, the read-only compliance statement, which is the longest one of the bunch 🌸
tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The read-only compliance statement for the IP Tunnel
MIB."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBInetGroup }
OBJECT tunnelIfHopLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfTOS
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfFlowLabel
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2),
ipv4z(3), ipv6z(4) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required.
An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation only needs to
support the addresses it actually supports on the
device."
OBJECT tunnelIfLocalInetAddress
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfRemoteInetAddress
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfEncapsLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."5. IANA Considerations ✨
Okay so this doc adds a brand new IANA-maintained textual convention (TC) 💅 to the IANAifType-MIB [IFTYPE]. It's called IANAtunnelType, the first version lives in Appendix A, and the current version is always at http://www.iana.org/assignments/ianaiftype-mib 🎀
The assignment policy for IANAtunnelType values should always be identical to the policy for assigning IANAifType values. Same rules, different list, periodt 💖
New tunnel types over IPv4 or IPv6 should not get IANAifType values. Instead, they should get IANAtunnelType values and reuse the interface type tunnel(131) 🧚 (ngl, this restriction doesn't apply to "tunnels" that aren't over IPv4 or IPv6, so those are a different story 🙈)
Before this, tunnel types that weren't point-to-point couldn't be properly expressed in the tunnel MIB, so they got IANAifType values as a workaround 🥲. This document fixes that glow-up. As a result, IANA has deprecated the sixToFour(215) IANAifType value in favor of the sixToFour(11) IANAtunnelType value 🦋
6. Security Considerations 🔐
Lowkey the most important section, so pay attention bestie 👀 A bunch of management objects in this MIB module have a MAX-ACCESS clause of read-write and/or read-create. Those objects can be sensitive or vulnerable in some network environments, and supporting SET operations in a non-secure environment without proper protection can seriously mess with network operations 😭
Unauthorized write access to any of the writable objects could cause unauthorized creation and/or manipulation of tunnels, resulting in a denial of service, or redirection of packets to an arbitrary destination. Not a vibe 💀
Some of the readable objects (anything with a MAX-ACCESS other than not-accessible) can also be sensitive or vulnerable depending on the network. So it's important to control even GET and/or NOTIFY access to them, and maybe even encrypt their values when sending them over the network via SNMP 🔒
Unauthorized read access to tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, tunnelIfLocalAddress, tunnelIfRemoteAddress, or any object in the tunnelConfigTable or tunnelInetConfigTable would reveal information about the tunnel topology 🗺️
SNMP versions before SNMPv3 did not include adequate security 😤 Even if the network itself is secure (for example by using IPSec), there's still no control over who on that secure network gets to access and GET/SET (read/change/create/delete) the objects in this MIB module. Iconic behavior from the old days, not it 🙅♀️
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Main character energy for security 👑
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is properly configured, so that only principals (users) with legitimate rights can GET or SET (change/create/delete) the objects 🫶
7. Changes Since RFC 2667 🌸
The IPv4-specific objects got deprecated, including tunnelIfLocalAddress, tunnelIfRemoteAddress, the tunnelConfigTable, and the tunnelMIBBasicGroup 🥀
New IP version-agnostic objects came in to replace them, including tunnelIfAddressType, tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the tunnelIMIBInetGroup ✨
The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress objects are read-write, not read-only. Big upgrade 🔥
The DESCRIPTION clauses of existing version-agnostic objects (like tunnelIfTOS) got updated. They used to be IPv4-specific text and now cover IPv6 as well 🌈
tunnelIfFlowLabel was added for tunnels over IPv6 🧚
The encapsulation method used to be an INTEGER type, and now it's an IANA-maintained textual convention 💜
8. Acknowledgements 🫶
This MIB module got updated based on feedback from the IETF's Interfaces MIB (IF-MIB), Point-to-Point Protocol Extensions (PPPEXT), and IPv6 Working Groups. Mike Heard and Ville Nuorvala also gave valuable MIB guidance on this version, so big thanks to them 💖
Appendix A: IANA Tunnel Type TC ✨
This appendix defines the initial content of the IANAtunnelType textual convention. The most up-to-date and current version is maintained in the IANAifType-MIB 📚
IANAtunnelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The encapsulation method used by a tunnel. The value
direct indicates that a packet is encapsulated
directly within a normal IP header, with no
intermediate header, and unicast to the remote tunnel
endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC
1933 IPv6-in-IPv4 tunnel). The value minimal indicates
that a Minimal Forwarding Header (RFC 2004) is
inserted between the outer header and the payload
packet. The value UDP indicates that the payload
packet is encapsulated within a normal UDP packet
(e.g., RFC 1234).
The values sixToFour, sixOverFour, and isatap
indicates that an IPv6 packet is encapsulated directly
within an IPv4 header, with no intermediate header,
and unicast to the destination determined by the 6to4,
6over4, or ISATAP protocol.
The remaining protocol-specific values indicate that a
header of the protocol of that name is inserted
between the outer header and the payload header.
The assignment policy for IANAtunnelType values is
identical to the policy for assigning IANAifType
values."
SYNTAX INTEGER {
other(1), -- none of the following
direct(2), -- no intermediate header
gre(3), -- GRE encapsulation
minimal(4), -- Minimal encapsulation
l2tp(5), -- L2TP encapsulation
pptp(6), -- PPTP encapsulation
l2f(7), -- L2F encapsulation
udp(8), -- UDP encapsulation
atmp(9), -- ATMP encapsulation
msdp(10), -- MSDP encapsulation
sixToFour(11), -- 6to4 encapsulation
sixOverFour(12), -- 6over4 encapsulation
isatap(13), -- ISATAP encapsulation
teredo(14) -- Teredo encapsulation
}Normative References 📖
[IFTYPE] Internet Assigned Numbers Authority, "IANAifType-MIB", http://www.iana.org/assignments/ianaiftype-mib.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC 3595, September 2003.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
Informative References ✨
okay bestie, here are the Informative References 📚 these are the sources the doc points to for background, so you don't need to read them to get the main idea 🧚
- [RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks", RFC 1234, June 1991.
- [RFC1241] Woodburn, R. and D. Mills, "A Scheme for an Internet Encapsulation Protocol: Version 1", RFC 1241, July 1991.
- [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
- [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.
- [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
- [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
- [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.
- [RFC2341] Valencia, A., Littlewood, M., and T. Kolar. "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black. "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [RFC2637] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
- [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
- [RFC2893] Gilligan, R. and E. Nordmark. "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
Author's Address 💖
meet the author, Dave Thaler 🦋 at Microsoft Corporation, the contact details are right here 👇
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.comFull Copyright Statement 🎀
ngl the legal stuff is a lot but here's the vibe, the copyright is held by The Internet Society (2005) 🌈
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💅
the IETF is being careful here, it's not making any claims about patents or other rights that might cover this tech 🫶
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🫶
last bit, and it's a good one 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 💜
📦 where this page comes from
- ietf: rfc4087 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms