Cisco Systems

Midtown Tower, 9-7-1,Akasaka Minato-Ku Tokyo 107-6227 Japan +81 3 6434 6543 shtsuchi@cisco.com

Cisco Systems

Shanghai China jacni@jacni.com

Operations & Management Area Internet Engineering Task Force Network Management Management Information base MIB SMIv2 6rd MAP 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. IP TUNNEL MIB[RFC4087] provides provisioning capability for IPv4 and IPv6 tunnel by SNMP. But it is not eqnough to support modern tunnel protocol such as 6rd[RFC5969] and MAP[draft-ietf-softwire-map]. The document describes extention of IP TUNNEL MIB[RFC4087] to support 6rd[RFC5969] and MAP[draft-ietf-softwire-map].

IP TUNNEL MIB[RFC4087] are used for managing tunnels of any type over IPv4 and IPv6 networks, including Generic Routing Encapslation (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. 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. This documents describes how to support IPv6 Rapid Deployment (6rd) [RFC5969] and Mapping of Address and Port (MAP)[draft-ietf-softwire-map] in IP TUNNEL MIB.

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 . 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 , STD 58, RFC 2579 and STD 58, RFC 2580 .

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 RFC 2119 .

IP TUNNEL MIB [RFC4087] are using provisioning for tunnel protocol, but could not support 6rd [RFC5969] and MAP [draft-ietf-softwire-map] due to lack of parameters. But MAP [draft-ietf-softwire-map] has compativility with DS-Lite [RFC6333] and stateless NAT64 [RFC6145]. Therefore if TUNNEL MIB once supports 6rd [RFC5969] and MAP[draft-ietf-softwire-map],it could manage many type of modern tunnels such as 6rd [RFC5969], MAP-T/MAP-E, DS-Lite [RFC6333], and XLAT464 CLAT [draft-ietf-v6ops-464xlat].

The MIB module specified herein provides one way to manage the 6rd and MAP devices thorough SNMP.

The 'system' group in the SNMPv2-MIB is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. The SAMPLE-MIB does not duplicate those objects.

The Interface MIB requires that any MIB module which is an adjunct of the Interface MIB clarify specific areas within the Interface MIB. These areas were intentionally left vague in the Interface MIB to avoid over constraining the MIB, thereby precluding management of certain media-types. Section 4 of enumerates several areas which a media-specific MIB must clarify. The implementor is referred to in order to understand the general intent of these areas.

The IP Tunnel MIB [RFC4087] contains objects common to all IP tunnels, including 6rd/MAP Additionally, tunnel encapsulation specific MIB (like what is defined in this document) extend the IP tunnel MIB to further describe encapsulation specific information. for example: 6rd case 6rd prefix, 6rd Prefix Length, IPv4Mask Length MAP case rule IPv6 prefix, rule IPv6 prefix Length, rule IPv4 prefix , rule IPv4 prefix length, EA-bit length, PSID tunnel method, BR address, source addresss could use tunnelIfEntry. 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 }

tunnelIfEncapsMethod must be sixRd(xx), MAPT(xx) and MAPE(xx). tunnelIfRemoteInetAddress must be BR address for CE. When 6rd, it would be IPv4 address. When MAP-T and MAP-E, it would be IPv6 address. 0.0.0.0 :: would be used for BR. TunnelIfXEntry would use for another prametors .

The following MIB module IMPORTS objects from SNMPv2-SMI , SNMPv2-TC , SNMPv2-CONF , and IF-MIB

tunnelIfXTable OBJECT-TYPE SYNTAX SEQUENCE OF TunnelIfXEntry MAX-ACCESS read-write STATUS current DESCRIPTION "This table contains additional objects for the tunnel interface table." ::= { tunnel xx } tunnelIfXEntry OBJECT-TYPE SYNTAX TunnelIfXEntry MAX-ACCESS read-write STATUS current DESCRIPTION "An entry containing additional information applicable to a particular tunnel interface." INDEX { ifIndex } ::= { tunnelIfXTable 1 } TunnelIfXEntry ::= SEQUENCE { SamPrex InetAddress, SamLength Integer32 BasePrex InetAddress, BaseLength Integer32 EAbit Integer32 PSID Integer32 } } SamPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "Stateless Adress Mapping Prex IPv4 for MAP,IPv6 for 6rd" := { TunnelIfXEntry 1 } SamLength OBJECT-TYPE SYNTAX Integer32(0..127) MAX-ACCESS read-write STATUS current DESCRIPTION "Stateless Adress Mapping length IPv4(0-31) for MAP,IPv6(0-127) for 6rd" := { TunnelIfXEntry 2 } BasePrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "rule IPv6 prefix for MAP, IPv4 address for 6rd" := { TunnelIfXEntry 3 } BaseLength OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "rule IPv6 prefix for MAP, IPv4 address for 6rd" := { TunnelIfXEntry 4 } EAbit OBJECT-TYPE SYNTAX Integer32(0..127) MAX-ACCESS read-write STATUS current DESCRIPTION "rule IPv6 prefix length for MAP, IPv4MaskLength for 6rd" := { TunnelIfXEntry 5 } PSID OBJECT-TYPE SYNTAX Integer32(0..127) MAX-ACCESS read-write STATUS current DESCRIPTION "EA bit for MAP,0 must be for 6rd" := { TunnelIfXEntry 6 } END

There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: SNMP versions prior to SNMPv3 did not include adequate security. 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 allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see , section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.

The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- TunnelIXEntry { tunnel XXX } IANAtunnelType ::= TEXTUAL-CONVENTION SYNTAX INTEGER { sixRd ("XX") -- 6rd encapsulation MAPT ("XX") -- MAP-T encapsulation MAPE ("XX") -- MAP-T encapsulation }

This template is based on contributions from the MIb Doctors, especially Juergen Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn.

Thanks to Marshall Rose for developing the XML2RFC format.

Invisible Worlds, Inc.

660 York Street San Francisco CA 94110 US +1 415 695 3975 mrose@not.invisible.net http://invisible.net/

General RFC Request for Comments I-D Internet-Draft XML Extensible Markup Language This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK] This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK] This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. Cisco Systems, Inc.

170 West Tasman Drive San Jose CA 95134-1706 US +1 408 526 5260 kzm@cisco.com

SNMPinfo

3763 Benton Street Santa Clara CA 95051 US +1 408 221 8702 dperkins@snmpinfo.com

TU Braunschweig

Bueltenweg 74/75 38106 Braunschweig DE +49 531 3913283 schoenw@ibr.cs.tu-bs.de

Cisco Systems, Inc.

170 West Tasman Drive San Jose CA 95134-1706 US +1 408 526 5260 kzm@cisco.com

SNMPinfo

3763 Benton Street Santa Clara CA 95051 US +1 408 221 8702 dperkins@snmpinfo.com

TU Braunschweig

Bueltenweg 74/75 38106 Braunschweig DE +49 531 3913283 schoenw@ibr.cs.tu-bs.de

Cisco Systems, Inc.

170 West Tasman Drive San Jose CA 95134-1706 US +1 408 526 5260 kzm@cisco.com

SNMPinfo

3763 Benton Street Santa Clara CA 95051 US +1 408 221 8702 dperkins@snmpinfo.com

TU Braunschweig

Bueltenweg 74/75 Braunschweig 38106 DE +49 531 3913283 schoenw@ibr.cs.tu-bs.de

The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.

The following changes have been made from draft-xxx-xxx-xxx-12 . [TODO] replace this list with your own list Updated the introductry boilerplate text, the security considerations section and the references to comply with the current IETF standards and guidelines. Additions and clarifications in various description clauses.

[TODO] This list of open issues should be cleared and removed before this document hits the IESG. Contributor addresses need to be updated