Request for Comments: 4087 Microsoft
Obsoletes: 2667 June 2005
Category: Standards Track
IP Tunnel MIB
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines a Management Information Base (MIB) module for use
with network management protocols in the Internet community. In
particular, it describes managed objects used for managing tunnels of
any type over IPv4 and IPv6 networks. Extension MIB modules may be
designed for managing protocol-specific objects. Likewise, extension
MIB modules may be designed for managing security-specific objects.
This MIB module does not support tunnels over non-IP networks.
Management of such tunnels may be supported by other MIB modules.
This memo obsoletes RFC 2667.
1. Introduction
Over the past several years, there has been a number of "tunneling"
protocols specified by the IETF (see [RFC1241] for an early
discussion of the model and examples). This document describes a
Management Information Base (MIB) module used for managing tunnels of
any type over IPv4 and IPv6 networks, including 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, among others.
Extension MIB modules may be designed for managing protocol-specific
objects. Likewise, extension MIB modules may be designed for
managing security-specific objects (e.g., IPsec [RFC2401]), and
traffic conditioner [RFC2474] objects.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the 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 contains two current tables and one deprecated table.
The current tables are:
o the Tunnel Interface Table, containing information on the tunnels
known to a router; and
o the Tunnel Inet Config Table, which can be used for dynamic
creation of tunnels, and also provides a mapping from endpoint
addresses to the current interface index value.
The version of this MIB module that appeared in RFC 2667 contained
the Tunnel Config Table, which mapped IPv4 endpoint addresses to
interface indexes. It is now deprecated in favor of the Tunnel Inet
Config Table.
3.1. Relationship to the Interfaces MIB
This section clarifies the relationship of this MIB module to the
Interfaces MIB [RFC2863]. Several areas of correlation are addressed
in the following subsections. The implementor is referred to the
Interfaces MIB document in order to understand the general intent of
these areas.
3.1.1. Layering Model
Each logical interface (physical or virtual) has an ifEntry in the
Interfaces MIB [RFC2863]. Tunnels are handled by creating a logical
interface (ifEntry) for each tunnel. These are then correlated,
using the ifStack table of the Interfaces MIB, to those interfaces on
which the local IPv4 or IPv6 addresses of the tunnels are configured.
The basic model, therefore, 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 usage can be defined in the MIB modules
defining the encapsulation below the network layer, and holds the
local IP addresses on which decapsulation will occur. For example,
if IP-in-IP encapsulation is being used, the ifRcvAddressTable can be
defined by IP-in-IP. If it is not specified, the default is that one
entry will exist for the tunnel interface, where ifRcvAddressAddress
contains 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 defining the encapsulation
below the network layer. For example, if IP-in-IP encapsulation [20]
is being used, the ifEntry is defined by IP-in-IP.
The ifType of a tunnel should be set to "tunnel" (131). An entry in
the IP Tunnel MIB module will exist for every ifEntry with this
ifType. An implementation of the IP Tunnel MIB module may allow
ifEntries to be created via the tunnelConfigTable. Creating a tunnel
will also add an entry in the ifTable and in the tunnelIfTable, and
deleting a tunnel will likewise delete the entry in the ifTable and
the tunnelIfTable.
The use of two different tables in this MIB module was an important
design decision. Traditionally, ifIndex values are chosen by agents,
and are permitted to change across restarts. Allowing row creation
directly in the Tunnel Interface Table, indexed by ifIndex, would
complicate row creation and/or cause interoperability problems (if
each agent had special restrictions on ifIndex). Instead, a separate
table is used that is indexed only by objects over which the manager
has control. Namely, these are the addresses of the tunnel endpoints
and the encapsulation protocol. Finally, an additional manager-
chosen ID is used in the index to support protocols such as L2F which
allow multiple tunnels between the same endpoints.
4. Definitions
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 }
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 }
tunnelIfEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel."
::= { tunnelIfEntry 3 }
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 }
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 }
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 }
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 }
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 }
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 }
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 }
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 }
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 }
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
}
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 }
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 }
tunnelConfigEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS not-accessible