draft-ietf-ipv6-inet-tunnel-mib-03.txt   rfc4087.txt 
Network Working Group D. Thaler Network Working Group D. Thaler
INTERNET-DRAFT Microsoft Request for Comments: 4087 Microsoft
Expires April 2005 October 2004 Obsoletes: 2667 June 2005
Category: Standards Track
IP Tunnel MIB IP Tunnel MIB
<draft-ietf-ipv6-inet-tunnel-mib-03.txt>
Status of this Memo Status of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware
will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than a "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html 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 Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Draft Inet Tunnel MIB October 2004
Abstract Abstract
This memo defines a Management Information Base (MIB) module for This memo defines a Management Information Base (MIB) module for use
use with network management protocols in the Internet community. with network management protocols in the Internet community. In
In particular, it describes managed objects used for managing particular, it describes managed objects used for managing tunnels of
tunnels of any type over IPv4 and IPv6 networks. Extension MIB any type over IPv4 and IPv6 networks. Extension MIB modules may be
modules may be designed for managing protocol-specific objects. designed for managing protocol-specific objects. Likewise, extension
Likewise, extension MIB modules may be designed for managing MIB modules may be designed for managing security-specific objects.
security-specific objects. This MIB module does not support This MIB module does not support tunnels over non-IP networks.
tunnels over non-IP networks. Management of such tunnels may be Management of such tunnels may be supported by other MIB modules.
supported by other MIB modules.
This memo obsoletes RFC 2667. This memo obsoletes RFC 2667.
1. Introduction 1. Introduction
Over the past several years, there have been a number of Over the past several years, there has been a number of "tunneling"
"tunneling" protocols specified by the IETF (see [RFC1241] for an protocols specified by the IETF (see [RFC1241] for an early
early discussion of the model and examples). This document discussion of the model and examples). This document describes a
describes a Management Information Base (MIB) module used for Management Information Base (MIB) module used for managing tunnels of
managing tunnels of any type over IPv4 and IPv6 networks, any type over IPv4 and IPv6 networks, including Generic Routing
including GRE [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal Encapsulation (GRE) [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal
Encapsulation [RFC2004], L2TP [RFC2661], PPTP [RFC2637], L2F Encapsulation [RFC2004], Layer 2 Tunneling Protocol (L2TP) [RFC2661],
[RFC2341], UDP (e.g., [RFC1234]), ATMP [RFC2107], and IPv6-in-IPv4 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2
[RFC2893] tunnels, among others. 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- Extension MIB modules may be designed for managing protocol-specific
specific objects. Likewise, extension MIB modules may be designed objects. Likewise, extension MIB modules may be designed for
for managing security-specific objects (e.g., IPsec [RFC2401]), managing security-specific objects (e.g., IPsec [RFC2401]), and
and traffic conditioner [RFC2474] objects. traffic conditioner [RFC2474] objects.
2. The Internet-Standard Management Framework 2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 Internet-Standard Management Framework, please refer to section 7 of
of RFC 3410 [RFC3410]. 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
Draft Inet Tunnel MIB October 2004
is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 Managed objects are accessed via a virtual information store, termed
[RFC2579] and STD 58, RFC 2580 [RFC2580]. 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 3. Overview
This MIB module contains two current tables and one deprecated This MIB module contains two current tables and one deprecated table.
table. The current tables are: The current tables are:
o the Tunnel Interface Table, containing information on the o the Tunnel Interface Table, containing information on the tunnels
tunnels known to a router; and known to a router; and
o the Tunnel Inet Config Table, which can be used for dynamic o the Tunnel Inet Config Table, which can be used for dynamic
creation of tunnels, and also provides a mapping from creation of tunnels, and also provides a mapping from endpoint
endpoint addresses to the current interface index value. addresses to the current interface index value.
The version of this MIB module that appeared in RFC 2667 contained The version of this MIB module that appeared in RFC 2667 contained
the Tunnel Config Table, which mapped IPv4 endpoint addresses to the Tunnel Config Table, which mapped IPv4 endpoint addresses to
interface indexes. It is now deprecated in favor of the Tunnel interface indexes. It is now deprecated in favor of the Tunnel Inet
Inet Config Table. Config Table.
3.1. Relationship to the Interfaces MIB 3.1. Relationship to the Interfaces MIB
This section clarifies the relationship of this MIB module to the This section clarifies the relationship of this MIB module to the
Interfaces MIB [RFC2863]. Several areas of correlation are Interfaces MIB [RFC2863]. Several areas of correlation are addressed
addressed in the following subsections. The implementor is in the following subsections. The implementor is referred to the
referred to the Interfaces MIB document in order to understand the Interfaces MIB document in order to understand the general intent of
general intent of these areas. these areas.
3.1.1. Layering Model 3.1.1. Layering Model
Each logical interface (physical or virtual) has an ifEntry in the Each logical interface (physical or virtual) has an ifEntry in the
Interfaces MIB [RFC2863]. Tunnels are handled by creating a Interfaces MIB [RFC2863]. Tunnels are handled by creating a logical
logical interface (ifEntry) for each tunnel. These are then interface (ifEntry) for each tunnel. These are then correlated,
correlated, using the ifStack table of the Interfaces MIB, to using the ifStack table of the Interfaces MIB, to those interfaces on
those interfaces on which the local IPv4 or IPv6 addresses of the which the local IPv4 or IPv6 addresses of the tunnels are configured.
tunnels are configured. The basic model, therefore, looks The basic model, therefore, looks something like this (for example):
something like this (for example):
| | | | | | | | | | | |
+--+ +---+ +--+ +---+ | | +--+ +---+ +--+ +---+ | |
|IP-in-IP| | GRE | | | |IP-in-IP| | GRE | | |
| tunnel | | tunnel | | | | tunnel | | tunnel | | |
Draft Inet Tunnel MIB October 2004
+--+ +---+ +--+ +---+ | | +--+ +---+ +--+ +---+ | |
| | | | | | <== attachment to underlying | | | | | | <== attachment to underlying
+--+ +---------+ +----------+ +--+ interfaces, to be provided +--+ +---------+ +----------+ +--+ interfaces, to be provided
| Physical interface | by ifStack table | Physical interface | by ifStack table
+--------------------------------+ +--------------------------------+
3.1.2. ifRcvAddressTable 3.1.2. ifRcvAddressTable
The ifRcvAddressTable usage can be defined in the MIB modules The ifRcvAddressTable usage can be defined in the MIB modules
defining the encapsulation below the network layer, and holds the defining the encapsulation below the network layer, and holds the
local IP addresses on which decapsulation will occur. For local IP addresses on which decapsulation will occur. For example,
example, if IP-in-IP encapsulation is being used, the if IP-in-IP encapsulation is being used, the ifRcvAddressTable can be
ifRcvAddressTable can be defined by IP- in-IP. If it is not defined by IP-in-IP. If it is not specified, the default is that one
specified, the default is that one entry will exist for the tunnel entry will exist for the tunnel interface, where ifRcvAddressAddress
interface, where ifRcvAddressAddress contains the local IP address contains the local IP address used for encapsulation/decapsulation
used for encapsulation/decapsulation (i.e., (i.e., tunnelIfLocalInetAddress in the Tunnel Interface Table).
tunnelIfLocalInetAddress in the Tunnel Interface Table).
3.1.3. ifEntry 3.1.3. ifEntry
IfEntries are defined in the MIB modules defining the IfEntries are defined in the MIB modules defining the encapsulation
encapsulation below the network layer. For example, if IP-in-IP below the network layer. For example, if IP-in-IP encapsulation [20]
encapsulation [20] is being used, the ifEntry is defined by IP-in- is being used, the ifEntry is defined by IP-in-IP.
IP.
The ifType of a tunnel should be set to "tunnel" (131). An entry The ifType of a tunnel should be set to "tunnel" (131). An entry in
in the IP Tunnel MIB module will exist for every ifEntry with this the IP Tunnel MIB module will exist for every ifEntry with this
ifType. An implementation of the IP Tunnel MIB module may allow ifType. An implementation of the IP Tunnel MIB module may allow
ifEntries to be created via the tunnelConfigTable. Creating a ifEntries to be created via the tunnelConfigTable. Creating a tunnel
tunnel will also add an entry in the ifTable and in the will also add an entry in the ifTable and in the tunnelIfTable, and
tunnelIfTable, and deleting a tunnel will likewise delete the deleting a tunnel will likewise delete the entry in the ifTable and
entry in the ifTable and the tunnelIfTable. 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 which 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
Draft Inet Tunnel MIB October 2004
the index to support protocols such as L2F which allow multiple The use of two different tables in this MIB module was an important
tunnels between the same endpoints. 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 4. Definitions
TUNNEL-MIB DEFINITIONS ::= BEGIN TUNNEL-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, transmission, MODULE-IDENTITY, OBJECT-TYPE, transmission,
Integer32, IpAddress FROM SNMPv2-SMI -- [RFC2578] Integer32, IpAddress FROM SNMPv2-SMI -- [RFC2578]
RowStatus, StorageType FROM SNMPv2-TC -- [RFC3579] RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, MODULE-COMPLIANCE,
OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
InetAddressType, InetAddressType,
InetAddress FROM INET-ADDRESS-MIB -- [RFC3291] InetAddress FROM INET-ADDRESS-MIB -- [RFC4001]
IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB -- [RFC3595] IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB -- [RFC3595]
ifIndex, ifIndex,
InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] InterfaceIndexOrZero FROM IF-MIB -- [RFC2863]
IANAtunnelType FROM IANAifType-MIB; -- [IFTYPE] IANAtunnelType FROM IANAifType-MIB; -- [IFTYPE]
tunnelMIB MODULE-IDENTITY tunnelMIB MODULE-IDENTITY
LAST-UPDATED "200410161200Z" -- October 16, 2004 LAST-UPDATED "200505160000Z" -- May 16, 2005
ORGANIZATION "IETF IP Version 6 (IPv6) Working Group" ORGANIZATION "IETF IP Version 6 (IPv6) Working Group"
CONTACT-INFO CONTACT-INFO
" Dave Thaler " Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
EMail: dthaler@microsoft.com" EMail: dthaler@microsoft.com"
DESCRIPTION DESCRIPTION
"The MIB module for management of IP Tunnels, "The MIB module for management of IP Tunnels,
independent of the specific encapsulation scheme in independent of the specific encapsulation scheme in
use. use.
Copyright (C) The Internet Society (date). This Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC yyyy; see version of this MIB module is part of RFC 4087; see
the RFC itself for full legal notices." the RFC itself for full legal notices."
REVISION "200505160000Z" -- May 16, 2005
Draft Inet Tunnel MIB October 2004
REVISION "200410161200Z" -- October 16, 2004
DESCRIPTION DESCRIPTION
"IPv4-specific objects were deprecated, including "IPv4-specific objects were deprecated, including
tunnelIfLocalAddress, tunnelIfRemoteAddress, the tunnelIfLocalAddress, tunnelIfRemoteAddress, the
tunnelConfigTable, and the tunnelMIBBasicGroup. tunnelConfigTable, and the tunnelMIBBasicGroup.
Added IP version-agnostic objects that should be used Added IP version-agnostic objects that should be used
instead, including tunnelIfAddressType, instead, including tunnelIfAddressType,
tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress,
the tunnelInetConfigTable, and the the tunnelInetConfigTable, and the
tunnelIMIBInetGroup. tunnelIMIBInetGroup.
skipping to change at page 6, line 33 skipping to change at page 5, line 30
Updated DESCRIPTION clauses of existing version- Updated DESCRIPTION clauses of existing version-
agnostic objects (e.g., tunnelIfTOS) that contained agnostic objects (e.g., tunnelIfTOS) that contained
IPv4-specific text to cover IPv6 as well. IPv4-specific text to cover IPv6 as well.
Added tunnelIfFlowLabel for tunnels over IPv6. Added tunnelIfFlowLabel for tunnels over IPv6.
The encapsulation method was previously an INTEGER The encapsulation method was previously an INTEGER
type, and is now an IANA-maintained textual type, and is now an IANA-maintained textual
convention. convention.
Published as RFC yyyy." Published as RFC 4087."
REVISION "199908241200Z" -- August 24, 1999 REVISION "199908241200Z" -- August 24, 1999
DESCRIPTION DESCRIPTION
"Initial version, published as RFC 2667." "Initial version, published as RFC 2667."
::= { transmission 131 } ::= { transmission 131 }
tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 } tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 }
tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 } tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 }
-- the IP Tunnel MIB-Group -- the IP Tunnel MIB-Group
-- --
-- a collection of objects providing information about -- a collection of objects providing information about
-- IP Tunnels -- IP Tunnels
tunnelIfTable OBJECT-TYPE tunnelIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelIfEntry SYNTAX SEQUENCE OF TunnelIfEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
Draft Inet Tunnel MIB October 2004
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The (conceptual) table containing information on "The (conceptual) table containing information on
configured tunnels." configured tunnels."
::= { tunnel 1 } ::= { tunnel 1 }
tunnelIfEntry OBJECT-TYPE tunnelIfEntry OBJECT-TYPE
SYNTAX TunnelIfEntry SYNTAX TunnelIfEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
skipping to change at page 8, line 4 skipping to change at page 6, line 45
"The address of the local endpoint of the tunnel "The address of the local endpoint of the tunnel
(i.e., the source address used in the outer IP (i.e., the source address used in the outer IP
header), or 0.0.0.0 if unknown or if the tunnel is header), or 0.0.0.0 if unknown or if the tunnel is
over IPv6. over IPv6.
Since this object does not support IPv6, it is Since this object does not support IPv6, it is
deprecated in favor of tunnelIfLocalInetAddress." deprecated in favor of tunnelIfLocalInetAddress."
::= { tunnelIfEntry 1 } ::= { tunnelIfEntry 1 }
tunnelIfRemoteAddress OBJECT-TYPE tunnelIfRemoteAddress OBJECT-TYPE
Draft Inet Tunnel MIB October 2004
SYNTAX IpAddress SYNTAX IpAddress
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"The address of the remote endpoint of the tunnel "The address of the remote endpoint of the tunnel
(i.e., the destination address used in the outer IP (i.e., the destination address used in the outer IP
header), or 0.0.0.0 if unknown, or an IPv6 address, or 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 the tunnel is not a point-to-point link (e.g., if it
is a 6to4 tunnel). is a 6to4 tunnel).
skipping to change at page 9, line 4 skipping to change at page 7, line 42
ipsec(2), -- IPsec security ipsec(2), -- IPsec security
other(3) other(3)
} }
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The method used by the tunnel to secure the outer IP "The method used by the tunnel to secure the outer IP
header. The value ipsec indicates that IPsec is used header. The value ipsec indicates that IPsec is used
between the tunnel endpoints for authentication or between the tunnel endpoints for authentication or
encryption or both. More specific security-related encryption or both. More specific security-related
Draft Inet Tunnel MIB October 2004
information may be available in a MIB module for the information may be available in a MIB module for the
security protocol in use." security protocol in use."
::= { tunnelIfEntry 5 } ::= { tunnelIfEntry 5 }
tunnelIfTOS OBJECT-TYPE tunnelIfTOS OBJECT-TYPE
SYNTAX Integer32 (-2..63) SYNTAX Integer32 (-2..63)
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The method used to set the high 6 bits (the "The method used to set the high 6 bits (the
skipping to change at page 9, line 28 skipping to change at page 8, line 15
IPv6 Traffic Class in the outer IP header. A value of IPv6 Traffic Class in the outer IP header. A value of
-1 indicates that the bits are copied from the -1 indicates that the bits are copied from the
payload's header. A value of -2 indicates that a payload's header. A value of -2 indicates that a
traffic conditioner is invoked and more information traffic conditioner is invoked and more information
may be available in a traffic conditioner MIB module. may be available in a traffic conditioner MIB module.
A value between 0 and 63 inclusive indicates that the A value between 0 and 63 inclusive indicates that the
bit field is set to the indicated value. bit field is set to the indicated value.
Note: instead of the name tunnelIfTOS, a better name Note: instead of the name tunnelIfTOS, a better name
would have been tunnelIfDSCPMethod, but the existing would have been tunnelIfDSCPMethod, but the existing
name appeared in RFC 2776 and existing objects cannot name appeared in RFC 2667 and existing objects cannot
be renamed." be renamed."
::= { tunnelIfEntry 6 } ::= { tunnelIfEntry 6 }
tunnelIfFlowLabel OBJECT-TYPE tunnelIfFlowLabel OBJECT-TYPE
SYNTAX IPv6FlowLabelOrAny SYNTAX IPv6FlowLabelOrAny
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The method used to set the IPv6 Flow Label value. "The method used to set the IPv6 Flow Label value.
This object need not be present in rows where This object need not be present in rows where
skipping to change at page 10, line 4 skipping to change at page 8, line 39
available in a traffic conditioner MIB. Any other available in a traffic conditioner MIB. Any other
value indicates that the Flow Label field is set to value indicates that the Flow Label field is set to
the indicated value." the indicated value."
::= { tunnelIfEntry 7 } ::= { tunnelIfEntry 7 }
tunnelIfAddressType OBJECT-TYPE tunnelIfAddressType OBJECT-TYPE
SYNTAX InetAddressType SYNTAX InetAddressType
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
Draft Inet Tunnel MIB October 2004
"The type of address in the corresponding "The type of address in the corresponding
tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress
objects." objects."
::= { tunnelIfEntry 8 } ::= { tunnelIfEntry 8 }
tunnelIfLocalInetAddress OBJECT-TYPE tunnelIfLocalInetAddress OBJECT-TYPE
SYNTAX InetAddress SYNTAX InetAddress
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 11, line 4 skipping to change at page 9, line 36
DESCRIPTION DESCRIPTION
"The maximum number of additional encapsulations "The maximum number of additional encapsulations
permitted for packets undergoing encapsulation at this permitted for packets undergoing encapsulation at this
node. A value of -1 indicates that no limit is node. A value of -1 indicates that no limit is
present (except as a result of the packet size)." present (except as a result of the packet size)."
REFERENCE "RFC 2473, section 4.1.1" REFERENCE "RFC 2473, section 4.1.1"
::= { tunnelIfEntry 11 } ::= { tunnelIfEntry 11 }
tunnelConfigTable OBJECT-TYPE tunnelConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelConfigEntry SYNTAX SEQUENCE OF TunnelConfigEntry
Draft Inet Tunnel MIB October 2004
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"The (conceptual) table containing information on "The (conceptual) table containing information on
configured tunnels. This table can be used to map a configured tunnels. This table can be used to map a
set of tunnel endpoints to the associated ifIndex set of tunnel endpoints to the associated ifIndex
value. It can also be used for row creation. Note value. It can also be used for row creation. Note
that every row in the tunnelIfTable with a fixed IPv4 that every row in the tunnelIfTable with a fixed IPv4
destination address should have a corresponding row in destination address should have a corresponding row in
the tunnelConfigTable, regardless of whether it was the tunnelConfigTable, regardless of whether it was
skipping to change at page 12, line 4 skipping to change at page 10, line 33
tunnelConfigEncapsMethod IANAtunnelType, tunnelConfigEncapsMethod IANAtunnelType,
tunnelConfigID Integer32, tunnelConfigID Integer32,
tunnelConfigIfIndex InterfaceIndexOrZero, tunnelConfigIfIndex InterfaceIndexOrZero,
tunnelConfigStatus RowStatus tunnelConfigStatus RowStatus
} }
tunnelConfigLocalAddress OBJECT-TYPE tunnelConfigLocalAddress OBJECT-TYPE
SYNTAX IpAddress SYNTAX IpAddress
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
Draft Inet Tunnel MIB October 2004
DESCRIPTION DESCRIPTION
"The address of the local endpoint of the tunnel, or "The address of the local endpoint of the tunnel, or
0.0.0.0 if the device is free to choose any of its 0.0.0.0 if the device is free to choose any of its
addresses at tunnel establishment time. addresses at tunnel establishment time.
Since this object does not support IPv6, it is Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigLocalAddress." deprecated in favor of tunnelInetConfigLocalAddress."
::= { tunnelConfigEntry 1 } ::= { tunnelConfigEntry 1 }
tunnelConfigRemoteAddress OBJECT-TYPE tunnelConfigRemoteAddress OBJECT-TYPE
skipping to change at page 13, line 4 skipping to change at page 11, line 29
DESCRIPTION DESCRIPTION
"An identifier used to distinguish between multiple "An identifier used to distinguish between multiple
tunnels of the same encapsulation method, with the tunnels of the same encapsulation method, with the
same endpoints. If the encapsulation protocol only same endpoints. If the encapsulation protocol only
allows one tunnel per set of endpoint addresses (such allows one tunnel per set of endpoint addresses (such
as for GRE or IP-in-IP), the value of this object is as for GRE or IP-in-IP), the value of this object is
1. For encapsulation methods (such as L2F) which 1. For encapsulation methods (such as L2F) which
allow multiple parallel tunnels, the manager is allow multiple parallel tunnels, the manager is
responsible for choosing any ID which does not responsible for choosing any ID which does not
conflict with an existing row, such as choosing a conflict with an existing row, such as choosing a
Draft Inet Tunnel MIB October 2004
random number. random number.
Since this object does not support IPv6, it is Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigID." deprecated in favor of tunnelInetConfigID."
::= { tunnelConfigEntry 4 } ::= { tunnelConfigEntry 4 }
tunnelConfigIfIndex OBJECT-TYPE tunnelConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS deprecated STATUS deprecated
skipping to change at page 14, line 4 skipping to change at page 12, line 26
To create a row in this table for an encapsulation To create a row in this table for an encapsulation
method which does not support multiple parallel method which does not support multiple parallel
tunnels with the same endpoints, the management tunnels with the same endpoints, the management
station should simply use a tunnelConfigID of 1, and station should simply use a tunnelConfigID of 1, and
set tunnelConfigStatus to createAndGo. For set tunnelConfigStatus to createAndGo. For
encapsulation methods such as L2F which allow multiple encapsulation methods such as L2F which allow multiple
parallel tunnels, the management station may select a parallel tunnels, the management station may select a
pseudo-random number to use as the tunnelConfigID and pseudo-random number to use as the tunnelConfigID and
set tunnelConfigStatus to createAndGo. In the event set tunnelConfigStatus to createAndGo. In the event
that this ID is already in use and an that this ID is already in use and an
Draft Inet Tunnel MIB October 2004
inconsistentValue is returned in response to the set inconsistentValue is returned in response to the set
operation, the management station should simply select operation, the management station should simply select
a new pseudo-random number and retry the operation. a new pseudo-random number and retry the operation.
Creating a row in this table will cause an interface Creating a row in this table will cause an interface
index to be assigned by the agent in an index to be assigned by the agent in an
implementation-dependent manner, and corresponding implementation-dependent manner, and corresponding
rows will be instantiated in the ifTable and the rows will be instantiated in the ifTable and the
tunnelIfTable. The status of this row will become tunnelIfTable. The status of this row will become
active as soon as the agent assigns the interface active as soon as the agent assigns the interface
skipping to change at page 15, line 4 skipping to change at page 13, line 23
tunnelInetConfigEntry OBJECT-TYPE tunnelInetConfigEntry OBJECT-TYPE
SYNTAX TunnelInetConfigEntry SYNTAX TunnelInetConfigEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An entry (conceptual row) containing the information "An entry (conceptual row) containing the information
on a particular configured tunnel. Note that there is on a particular configured tunnel. Note that there is
a 128 subid maximum for object OIDs. Implementers a 128 subid maximum for object OIDs. Implementers
need to be aware that if the total number of octets in need to be aware that if the total number of octets in
Draft Inet Tunnel MIB October 2004
tunnelInetConfigLocalAddress and tunnelInetConfigLocalAddress and
tunnelInetConfigRemoteAddress exceeds 110 then OIDs of tunnelInetConfigRemoteAddress exceeds 110 then OIDs of
column instances in this table will have more than 128 column instances in this table will have more than 128
sub-identifiers and cannot be accessed using SNMPv1, sub-identifiers and cannot be accessed using SNMPv1,
SNMPv2c, or SNMPv3. In practice this is not expected SNMPv2c, or SNMPv3. In practice this is not expected
to be a problem since IPv4 and IPv6 addresses will not to be a problem since IPv4 and IPv6 addresses will not
cause the limit to be reached, but if other types are cause the limit to be reached, but if other types are
supported by an agent, care must be taken to ensure supported by an agent, care must be taken to ensure
that the sum of the lengths do not cause the limit to that the sum of the lengths do not cause the limit to
be exceeded." be exceeded."
skipping to change at page 16, line 4 skipping to change at page 14, line 20
::= { tunnelInetConfigEntry 1 } ::= { tunnelInetConfigEntry 1 }
tunnelInetConfigLocalAddress OBJECT-TYPE tunnelInetConfigLocalAddress OBJECT-TYPE
SYNTAX InetAddress SYNTAX InetAddress
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The address of the local endpoint of the tunnel, or "The address of the local endpoint of the tunnel, or
0.0.0.0 (for IPv4) or :: (for IPv6) if the device is 0.0.0.0 (for IPv4) or :: (for IPv6) if the device is
free to choose any of its addresses at tunnel free to choose any of its addresses at tunnel
Draft Inet Tunnel MIB October 2004
establishment time." establishment time."
::= { tunnelInetConfigEntry 2 } ::= { tunnelInetConfigEntry 2 }
tunnelInetConfigRemoteAddress OBJECT-TYPE tunnelInetConfigRemoteAddress OBJECT-TYPE
SYNTAX InetAddress SYNTAX InetAddress
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The address of the remote endpoint of the tunnel." "The address of the remote endpoint of the tunnel."
::= { tunnelInetConfigEntry 3 } ::= { tunnelInetConfigEntry 3 }
skipping to change at page 17, line 4 skipping to change at page 15, line 17
tunnelInetConfigIfIndex OBJECT-TYPE tunnelInetConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"If the value of tunnelInetConfigStatus for this row "If the value of tunnelInetConfigStatus for this row
is active, then this object contains the value of is active, then this object contains the value of
ifIndex corresponding to the tunnel interface. A ifIndex corresponding to the tunnel interface. A
value of 0 is not legal in the active state, and means value of 0 is not legal in the active state, and means
Draft Inet Tunnel MIB October 2004
that the interface index has not yet been assigned." that the interface index has not yet been assigned."
::= { tunnelInetConfigEntry 6 } ::= { tunnelInetConfigEntry 6 }
tunnelInetConfigStatus OBJECT-TYPE tunnelInetConfigStatus OBJECT-TYPE
SYNTAX RowStatus SYNTAX RowStatus
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The status of this row, by which new entries may be "The status of this row, by which new entries may be
created, or old entries deleted from this table. The created, or old entries deleted from this table. The
skipping to change at page 18, line 5 skipping to change at page 16, line 14
tunnelIfTable. The status of this row will become tunnelIfTable. The status of this row will become
active as soon as the agent assigns the interface active as soon as the agent assigns the interface
index, regardless of whether the interface is index, regardless of whether the interface is
operationally up. operationally up.
Deleting a row in this table will likewise delete the Deleting a row in this table will likewise delete the
corresponding row in the ifTable and in the corresponding row in the ifTable and in the
tunnelIfTable." tunnelIfTable."
::= { tunnelInetConfigEntry 7 } ::= { tunnelInetConfigEntry 7 }
Draft Inet Tunnel MIB October 2004
tunnelInetConfigStorageType OBJECT-TYPE tunnelInetConfigStorageType OBJECT-TYPE
SYNTAX StorageType SYNTAX StorageType
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The storage type of this row. If the row is "The storage type of this row. If the row is
permanent(4), no objects in the row need be writable." permanent(4), no objects in the row need be writable."
::= { tunnelInetConfigEntry 8 } ::= { tunnelInetConfigEntry 8 }
-- conformance information -- conformance information
skipping to change at page 19, line 4 skipping to change at page 17, line 11
OBJECT tunnelIfTOS OBJECT tunnelIfTOS
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION DESCRIPTION
"Write access is not required." "Write access is not required."
OBJECT tunnelConfigStatus OBJECT tunnelConfigStatus
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION DESCRIPTION
"Write access is not required." "Write access is not required."
Draft Inet Tunnel MIB October 2004
::= { tunnelMIBCompliances 1 } ::= { tunnelMIBCompliances 1 }
tunnelMIBInetFullCompliance MODULE-COMPLIANCE tunnelMIBInetFullCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The full compliance statement for the IP Tunnel MIB." "The full compliance statement for the IP Tunnel MIB."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { tunnelMIBInetGroup } MANDATORY-GROUPS { tunnelMIBInetGroup }
OBJECT tunnelIfAddressType OBJECT tunnelIfAddressType
skipping to change at page 19, line 48 skipping to change at page 18, line 4
OBJECT tunnelIfTOS OBJECT tunnelIfTOS
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION DESCRIPTION
"Write access is not required." "Write access is not required."
OBJECT tunnelIfFlowLabel OBJECT tunnelIfFlowLabel
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION DESCRIPTION
"Write access is not required." "Write access is not required."
OBJECT tunnelIfAddressType OBJECT tunnelIfAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2), SYNTAX InetAddressType { ipv4(1), ipv6(2),
ipv4z(3), ipv6z(4) } ipv4z(3), ipv6z(4) }
Draft Inet Tunnel MIB October 2004
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION DESCRIPTION
"Write access is not required. "Write access is not required.
An implementation is only required to support IPv4 An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation only needs to and/or IPv6 addresses. An implementation only needs to
support the addresses it actually supports on the support the addresses it actually supports on the
device." device."
OBJECT tunnelIfLocalInetAddress OBJECT tunnelIfLocalInetAddress
skipping to change at page 21, line 4 skipping to change at page 19, line 4
-- units of conformance -- units of conformance
tunnelMIBBasicGroup OBJECT-GROUP tunnelMIBBasicGroup OBJECT-GROUP
OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress, OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress,
tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS, tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS,
tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus } tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus }
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"A collection of objects to support basic management "A collection of objects to support basic management
Draft Inet Tunnel MIB October 2004
of IPv4 Tunnels. Since this group cannot support of IPv4 Tunnels. Since this group cannot support
IPv6, it is deprecated in favor of IPv6, it is deprecated in favor of
tunnelMIBInetGroup." tunnelMIBInetGroup."
::= { tunnelMIBGroups 1 } ::= { tunnelMIBGroups 1 }
tunnelMIBInetGroup OBJECT-GROUP tunnelMIBInetGroup OBJECT-GROUP
OBJECTS { tunnelIfAddressType, tunnelIfLocalInetAddress, OBJECTS { tunnelIfAddressType, tunnelIfLocalInetAddress,
tunnelIfRemoteInetAddress, tunnelIfEncapsMethod, tunnelIfRemoteInetAddress, tunnelIfEncapsMethod,
tunnelIfEncapsLimit, tunnelIfEncapsLimit,
tunnelIfHopLimit, tunnelIfTOS, tunnelIfFlowLabel, tunnelIfHopLimit, tunnelIfTOS, tunnelIfFlowLabel,
skipping to change at page 21, line 30 skipping to change at page 19, line 27
DESCRIPTION DESCRIPTION
"A collection of objects to support basic management "A collection of objects to support basic management
of IPv4 and IPv6 Tunnels." of IPv4 and IPv6 Tunnels."
::= { tunnelMIBGroups 2 } ::= { tunnelMIBGroups 2 }
END END
5. IANA Considerations 5. IANA Considerations
This document introduces a new IANA-maintained textual convention This document introduces a new IANA-maintained textual convention
(TC) which is to be added to the IANAifType-MIB [IFTYPE]. The (TC) which has been added to the IANAifType-MIB [IFTYPE]. The
initial version of this IANAtunnelType TC can be found in Appendix initial version of this IANAtunnelType TC can be found in Appendix A.
A. The current version of the textual convention can be accessed The current version of the textual convention can be accessed at
at http://www.iana.org/assignments/ianaiftype-mib http://www.iana.org/assignments/ianaiftype-mib
The assignment policy for IANAtunnelType values should always be The assignment policy for IANAtunnelType values should always be
identical to the policy for assigning IANAifType values. identical to the policy for assigning IANAifType values.
New types of tunnels over IPv4 or IPv6 should not be assigned New types of tunnels over IPv4 or IPv6 should not be assigned
IANAifType values. Instead, they should be assigned IANAifType values. Instead, they should be assigned IANAtunnelType
IANAtunnelType values and hence reuse the interface type values and hence reuse the interface type tunnel(131). (Note this
tunnel(131). (Note this restriction does not apply to "tunnels" restriction does not apply to "tunnels" which are not over IPv4 or
which are not over IPv4 or IPv6.) IPv6.)
Previously tunnel types which were not point-to-point tunnels were Previously, tunnel types that were not point-to-point tunnels were
problematic in that they could not be properly expressed in the problematic in that they could not be properly expressed in the
tunnel MIB, and hence were assigned IANAifType values. This tunnel MIB, and hence were assigned IANAifType values. This document
document now corrects this problem, and as a result, IANA should now corrects this problem, and as a result, IANA has deprecated the
deprecate the sixToFour(215) IANAifType value in favor of the sixToFour(215) IANAifType value in favor of the sixToFour(11)
sixToFour(11) IANAtunnelType value. IANAtunnelType value.
Draft Inet Tunnel MIB October 2004
6. Security Considerations 6. Security Considerations
There are a number of management objects defined in this MIB There are a number of management objects defined in this MIB module
module with a MAX-ACCESS clause of read-write and/or read-create. with a MAX-ACCESS clause of read-write and/or read-create. Such
Such objects may be considered sensitive or vulnerable in some objects may be considered sensitive or vulnerable in some network
network environments. The support for SET operations in a non- environments. The support for SET operations in a non-secure
secure environment without proper protection can have a negative environment without proper protection can have a negative effect on
effect on network operations. network operations.
Unauthorized write access to any of the writable objects could Unauthorized write access to any of the writable objects could cause
cause unauthorized creation and/or manipulation of tunnels, unauthorized creation and/or manipulation of tunnels, resulting in a
resulting in a denial of service, or redirection of packets to an denial of service, or redirection of packets to an arbitrary
arbitrary destination. destination.
Some of the readable objects in this MIB module (i.e., objects Some of the readable objects in this MIB module (i.e., objects with a
with a MAX-ACCESS other than not-accessible) may be considered MAX-ACCESS other than not-accessible) may be considered sensitive or
sensitive or vulnerable in some network environments. It is thus vulnerable in some network environments. It is thus important to
important to control even GET and/or NOTIFY access to these control even GET and/or NOTIFY access to these objects and possibly
objects and possibly to even encrypt the values of these objects to even encrypt the values of these objects when sending them over
when sending them over the network via SNMP. the network via SNMP.
Unauthorized read access to tunnelIfLocalInetAddress, Unauthorized read access to tunnelIfLocalInetAddress,
tunnelIfRemoteInetAddress, tunnelIfLocalAddress, tunnelIfRemoteInetAddress, tunnelIfLocalAddress,
tunnelIfRemoteAddress, or any object in the tunnelConfigTable or tunnelIfRemoteAddress, or any object in the tunnelConfigTable or
tunnelInetConfigTable would reveal information about the tunnel tunnelInetConfigTable would reveal information about the tunnel
topology. topology.
SNMP versions prior to SNMPv3 did not include adequate security. SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec), Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the allowed to access and GET/SET (read/change/create/delete) the objects
objects in this MIB module. in this MIB module.
It is RECOMMENDED that implementers consider the security features It is RECOMMENDED that implementers consider the security features as
as provided by the SNMPv3 framework (see [RFC3410], section 8), provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms including full support for the SNMPv3 cryptographic mechanisms (for
(for authentication and privacy). authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access instance of this MIB module is properly configured to give access to
to the objects only to those principals (users) that have the objects only to those principals (users) that have legitimate
legitimate rights to indeed GET or SET (change/create/delete) rights to indeed GET or SET (change/create/delete) them.
Draft Inet Tunnel MIB October 2004
them.
7. Changes since RFC 2667 7. Changes Since RFC 2667
IPv4-specific objects were deprecated, including IPv4-specific objects were deprecated, including
tunnelIfLocalAddress, tunnelIfRemoteAddress, the tunnelIfLocalAddress, tunnelIfRemoteAddress, the tunnelConfigTable,
tunnelConfigTable, and the tunnelMIBBasicGroup. and the tunnelMIBBasicGroup.
Added IP version-agnostic objects that should be used instead, Added IP version-agnostic objects that should be used instead,
including tunnelIfAddressType, tunnelIfLocalInetAddress, including tunnelIfAddressType, tunnelIfLocalInetAddress,
tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the
tunnelIMIBInetGroup. tunnelIMIBInetGroup.
The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress
objects are read-write, rather than read-only. objects are read-write, rather than read-only.
Updated DESCRIPTION clauses of existing version-agnostic objects Updated DESCRIPTION clauses of existing version-agnostic objects
(e.g., tunnelIfTOS) that contained IPv4-specific text to cover (e.g., tunnelIfTOS) that contained IPv4-specific text to cover IPv6
IPv6 as well. as well.
Added tunnelIfFlowLabel for tunnels over IPv6. Added tunnelIfFlowLabel for tunnels over IPv6.
The encapsulation method was previously an INTEGER type, and is The encapsulation method was previously an INTEGER type, and is now
now an IANA-maintained textual convention. an IANA-maintained textual convention.
8. Acknowledgements 8. Acknowledgements
This MIB module was updated based on feedback from the IETF's This MIB module was updated based on feedback from the IETF's
Interfaces MIB (IF-MIB), Point-to-Point Protocol Extensions Interfaces MIB (IF-MIB), Point-to-Point Protocol Extensions (PPPEXT),
(PPPEXT), and IPv6 Working Groups. Mike Heard and Ville Nuorvala and IPv6 Working Groups. Mike Heard and Ville Nuorvala also provided
also provided valuable MIB guidance on this version. valuable MIB guidance on this version.
9. Author's Address
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Draft Inet Tunnel MIB October 2004
10. 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.
[RFC3291] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet
Network Addresses", RFC 3291, May 2002.
[RFC3595] B. Wijnen, "Textual Conventions for IPv6 Flow Label",
RFC 3595, September 2003.
11. Informative References
[RFC1234] D. Provan, "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.
Draft Inet Tunnel MIB October 2004
[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] 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.
Draft Inet Tunnel MIB October 2004
12. Appendix A: IANA Tunnel Type TC Appendix A: IANA Tunnel Type TC
This appendix defines the initial content of the IANAtunnelType This appendix defines the initial content of the IANAtunnelType
textual convention which should appear in the IANAifType-MIB. textual convention. The most up-to-date and current version is
maintained in the IANAifType-MIB.
IANAtunnelType ::= TEXTUAL-CONVENTION IANAtunnelType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The encapsulation method used by a tunnel. The value "The encapsulation method used by a tunnel. The value
direct indicates that a packet is encapsulated direct indicates that a packet is encapsulated
directly within a normal IP header, with no directly within a normal IP header, with no
intermediate header, and unicast to the remote tunnel intermediate header, and unicast to the remote tunnel
endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC
1933 IPv6-in-IPv4 tunnel). The value minimal indicates 1933 IPv6-in-IPv4 tunnel). The value minimal indicates
skipping to change at page 27, line 4 skipping to change at page 22, line 51
direct(2), -- no intermediate header direct(2), -- no intermediate header
gre(3), -- GRE encapsulation gre(3), -- GRE encapsulation
minimal(4), -- Minimal encapsulation minimal(4), -- Minimal encapsulation
l2tp(5), -- L2TP encapsulation l2tp(5), -- L2TP encapsulation
pptp(6), -- PPTP encapsulation pptp(6), -- PPTP encapsulation
l2f(7), -- L2F encapsulation l2f(7), -- L2F encapsulation
udp(8), -- UDP encapsulation udp(8), -- UDP encapsulation
atmp(9), -- ATMP encapsulation atmp(9), -- ATMP encapsulation
msdp(10), -- MSDP encapsulation msdp(10), -- MSDP encapsulation
sixToFour(11), -- 6to4 encapsulation sixToFour(11), -- 6to4 encapsulation
Draft Inet Tunnel MIB October 2004
sixOverFour(12), -- 6over4 encapsulation sixOverFour(12), -- 6over4 encapsulation
isatap(13), -- ISATAP encapsulation isatap(13), -- ISATAP encapsulation
teredo(14) -- Teredo encapsulation teredo(14) -- Teredo encapsulation
} }
13. Full Copyright Statement Normative References
Copyright (C) The Internet Society (2004). This document is [IFTYPE] Internet Assigned Numbers Authority, "IANAifType-MIB",
subject to the rights, licenses and restrictions contained in BCP http://www.iana.org/assignments/ianaiftype-mib.
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE IPv6 Specification", RFC 2473, December 1998.
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.
14. Intellectual Property [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
[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
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Full Copyright Statement
Copyright (C) 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 takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; neither does it represent might or might not be available; nor does it represent that it has
that it has made any effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the IETF's procedures with respect to rights in on the procedures with respect to rights in RFC documents can be
standards-track and standards-related documentation can be found found in BCP 78 and BCP 79.
in BCP-11. Copies of claims of rights made available for
publication 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 implementors
or users of this specification can be obtained from the IETF
Secretariat.
The IETF invites any interested party to bring to its attention Copies of IPR disclosures made to the IETF Secretariat and any
any copyrights, patents or patent applications, or other assurances of licenses to be made available, or the result of an
proprietary rights which may cover technology that may be required attempt made to obtain a general license or permission for the use of
to practice this standard. Please address the information to the such proprietary rights by implementers or users of this
IETF Executive Director. 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
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/