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 188.8.131.52 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 ................................ 70 1.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. 184.108.40.206 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.