RFC 3371
Layer Two Tunneling Protocol "L2TP" Management Information Base
Pages: 70
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 11
Network Working Group E. Caves Request for Comments: 3371 Occam Networks Category: Standards Track P. Calhoun Black Storm Networks R. Wheeler DoubleWide Software August 2002 Layer Two Tunneling Protocol "L2TP" Management Information Base 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 (2002). All Rights Reserved.Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Layer 2 Tunneling Protocol (L2TP).
Table of Contents
1.0 Introduction .......................................... 2 2.0 The SNMP Management Framework ........................... 2 3.0 Overview ................................................ 4 3.1 Relationship to the Interface MIB........................ 5 3.1.1 Layering Model .......................................... 5 3.1.2 Interface MIB Object..................................... 7 3.1.2.1 L2TP Tunnel Interfaces .................................. 7 3.2 Relationship to other MIBs .............................. 10 3.2.1 Relationship to the IP Tunnel MIB ....................... 10 3.3 L2TP Tunnel Creation .................................... 10 3.4 L2TP Session Mapping .................................... 10 4.0 L2TP Object Definitions ................................. 11 5.0 Security Considerations ................................. 66 6.0 Acknowledgements ........................................ 67 7.0 References .............................................. 67 8.0 Authors' Addresses ...................................... 69 9.0 Full Copyright Statement ................................ 701.0 Introduction
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it describes managed objects used for managing L2TP devices. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].2.0 The SNMP Management Framework
The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of the
SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and
RFC 1906 [RFC1906]. The third version of the message protocol is
called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572
[RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[RFC1905].
o A set of fundamental applications described in RFC 2573 [RFC2573]
and the view-based access control mechanism described in RFC 2575
[RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
3.0 Overview
The objects defined in this MIB are to be used when describing Layer Two Tunneling Protocol (L2TP) tunnels. The L2TP protocol is defined in [RFC2661]. This MIB consists of seven groups briefly described below: l2tpConfigGroup l2tpStatsGroup These two groups of objects provide information on the configuration, state and statistics of the L2TP protocol, its tunnels and sessions. These groups are mandatory for implementors of this MIB. l2tpDomainGroup This optional group of objects provides configuration, state and statistical information for L2TP tunnel endpoint domains. A L2TP tunnel endpoint domain is considered to be a collection of L2TP devices typically belonging to a common administrative domain or geographic location. l2tpMappingGroup This optional group contains mapping tables to assist management applications to map between protocol identifiers and table indices. l2tpIpUdpGroup This group provides the state and statistics information for L2TP tunnels which are being transported by UDP/IP. This group is mandatory for L2TP implementations that support L2TP over UDP/IP. l2tpSecurityGroup This group is optional for SNMP agents which support both authentication and privacy of SNMP messages for the management of L2TP keys. l2tpTrapGroup This group contains the notifications that could be generated by a L2TP implementation. l2tpHCPacketGroup This group is optional for L2TP implementations that could potentially overflow the L2TP Domain tables 32-bit statistics counters in less than an hour.
3.1 Relationship to the Interface MIB
This section clarifies the relationship of this MIB 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
This MIB contains several tables which are extensions to the IP Tunnel MIB described in [RFC2667] which itself defines extensions to the Interface MIB [RFC2863]. An L2TP tunnel is represented as a separate identifiable logical interface sub-layer. The tunnel stack layering model is described in [RFC2667]. In addition to that described in [RFC2667] an L2TP tunnel will not be at the top of the ifStack on a L2TP device that is acting as a L2TP Network Server (LNS). In this case PPP interfaces will be layered on top of the tunnel interface.
In the example diagram below, the interface layering is shown as it
might appear at the LNS.
+--------------------------------------------+
| Network Layer Protocol |
+-+-----------+-------------+--------+-------+
| | | |
| +-+--+ | |
| |MPPP| | | <=== PPP Multilink I/F
| ++--++ | |
| | | | |
| +--+ +--+ | |
| | | | |
| +-+-+ +-+-+ +-+-+ +-+-+
| |PPP| |PPP| |PPP| |PPP| <=== PPP I/F
| +-+-+ +-+-+ +-+-+ +-+-+
| | | | |
| +----+--------+--------+--------+----+
| | L2TP Tunnel I/F |
| +------------------+-----------------+
| |
+-+---------------------+------+
| Ethernet |
+------------------------------+
The ifStackTable is used to describe the layering of the interface
sub-layers. For the example given above the ifTable and ifStackTable
may appear as follows:
ifIndex ifType Tunnel MIB tables Description
1 ethernetCsmacd(6) Ethernet interface
2 tunnel(131) tunnelIfTable Tunnel interface
l2tpTunnelConfigTable
l2tpTunnelStatsTable
3 ppp(23) PPP interface #1
4 ppp(23) PPP interface #2
5 ppp(23) PPP interface #3
6 ppp(23) PPP interface #4
7 mlppp(108) MLPPP interface
The corresponding ifStack table entries would then be:
ifStackTable Entries
HigherLayer LowerLayer
0 5
0 6
0 7
1 0
2 1
3 2
4 2
5 2
6 2
7 3
7 4
L2TP Access Concentrator (LAC) tunnel interfaces on the other hand
appear at the top of the interface layering stack. In this case the
layering model is as described in [RFC2667].
However in order to support the tunneling of packets received from
interfaces carrying framed PPP packets on the LAC to the LNS (and the
propagation of decapsulated PPP packets to that interface) additional
configuration is required. This is further described in section 3.4.
3.1.2 Interface MIB Objects
Except where noted in the tables below, all objects MUST be supported
from the ifGeneralInformationGroup and one of the following three
groups:
o ifPacketGroup OR
o ifHCPacketGroup OR
o ifVHCPacketGroup
depending on the particular implementation.
The following tables describe how objects from the
ifGeneralInformationGroup and ifPacketGroup (similar support should
be provided for the high and very high capacity packet groups) are to
be interpreted and supported for L2TP tunnel interfaces.
3.1.2.1 L2TP Tunnel Interfaces
All Interface MIB objects not listed in the above groups for L2TP
tunnel interfaces MUST be supported as described in [RFC2863].
Interface MIB Object Support Description
==================== ========================================
ifTable.ifDescr Refer to the Interface MIB.
ifTable.ifType tunnel(131).
ifTable.ifMtu Dependent on the tunnel transport layer.
For UDP/IP transports the MTU should
be 65467 (65535-60(IP)-8(UDP)).
ifTable.ifSpeed Return zero.
ifTable.ifPhyAddress The assigned tunnel identifier.
ifTable.ifAdminStatus Setting ifAdminStatus to 'up' injects a
'Local Open' request into the tunnel FSM.
Setting ifAdminStatus to 'down' injects
a 'Tunnel Close' event into the tunnel
FSM. Setting ifAdminStatus to 'testing'
is not currently defined but could be
used to test tunnel connectivity.
ifTable.ifOperStatus ifOperStatus values are to be interpreted
as follows:
'up' - tunnel is established.
'down' - administratively down
or peer unreachable.
'testing' - in some test mode.
'unknown' - status cannot be
determined for some
reason.
'dormant' - operational but
waiting for local or
remote trigger to bring
up the tunnel.
'notPresent' - configuration missing.
'lowerLayerDown' - down due to state of
lower-layer
interface(s).
ifTable.ifInOctets The total number of octets received on the
tunnel including control and payload
octets.
ifTable.ifInUcastPkts The total number of packets received on
the tunnel including control and payload
packets.
ifTable.ifInDiscards The total number of received packets that
were discarded on both control and payload
channels.
ifTable.ifInErrors The total number of packets received in
error including control and payload
packets.
ifTable.ifInUnknownProtos
Return zero.
ifTable.ifOutOctets The total number of octets transmitted
from the tunnel including control and
payload octets.
ifTable.ifOutUcastPkts The total number of packets transmitted
from the tunnel including control and
payload packets.
ifTable.ifOutDiscards The total number of discarded packets that
were requested to be transmitted including
control and payload packets.
ifTable.ifOutErrors The total number of packets that were
requested to be transmitted that were in
error including control and payload
packets.
ifXTable.ifName Refer to the Interface MIB.
ifXTable.ifInMulticastPkts
Return zero.
ifXTable.ifInBroadcastPkts
Return zero.
ifXTable.ifOutMulticastPkts
Return zero.
ifXTable.ifOutBroadcastPkts
Return zero.
ifXTable.ifOutBroadcastPkts
Return zero.
ifXTable.ifLinkUpDownTrapEnable
Default set to enabled(1).
ifXTable.ifHighSpeed Return zero.
ifXTable.ifPromiscuousMode
Set to false(2).
ifXTable.ifConnectorPresent
Set to false(2).
3.2 Relationship to other MIBs
3.2.1 Relationship to the IP Tunnel MIB
The IP Tunnel MIB [RFC2667] describes tunnel interfaces that have an
ifType of tunnel(131). The IP Tunnel MIB is considered to contain a
collection of objects common to all IP tunneling protocols, including
L2TP. In addition to the IP Tunnel MIB, tunnel encapsulation
specific MIBs (like this MIB) extend the IP Tunnel MIB to further
describe encapsulation specific information. Implementation of the
IP Tunnel MIB is required for L2TP tunnels over IP.
3.3 L2TP Tunnel Creation
Tunnel creation is detailed for tunnels over IP in the IP Tunnel MIB.
The creation of a tunnelIfEntry in [RFC2667] when the encapsulation
method is "l2tp" will have the side effect of creating entries in the
l2tpTunnelConfigTable, l2tpTunnelStatsTable and the
l2tpUdpStatsTable's.
The creation of L2TP tunnel interfaces over transports other than IP
is expected to be defined in the MIB definition for that specific
L2TP tunnel transport.
3.4 L2TP Session Mapping
The l2tpSessionMapTable table allows management applications to
determine which session within a tunnel a particular interface
(either a PPP or DS0 interface) is mapped to. On the LAC it also
provides a management application the ability to map a particular
physical or virtual interface terminating a PPP link to a particular
L2TP tunnel. This is required since the interface stacking as
performed (and instrumented by the ifStackTable) on the LNS cannot be
applied at the LAC.
The following diagram illustrates the conceptual binding that occurs.
+---------------------------------------+
| L2TP Session Map Database |
+----------+-----------------+----------+
| |
+---+---+ +-----+------+
| ds0 | | Tunnel I/F |
+---+---+ +-----+------+
| |
+---+---+ +-----+------+
| ds1 | | Ethernet |
+-------+ +------------+
The stacking of the individual interface stacks would be described by
the ifStackTable.
(page 11 continued on part 2)