idnits 2.17.1 draft-ietf-ifmib-tunnel-mib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 178: '...he IP Tunnel MIB MAY allow ifEntries t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (27 July 1998) is 9376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2271 (ref. '1') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '6') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '7') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '11') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '12') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '15') (Obsoleted by RFC 2575) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '16') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '17') == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-04 == Outdated reference: A later version (-10) exists of draft-ietf-pppext-pptp-02 ** Downref: Normative reference to an Informational draft: draft-ietf-pppext-pptp (ref. '21') == Outdated reference: A later version (-05) exists of draft-ietf-pppext-l2tp-mib-00 -- Possible downref: Normative reference to a draft: ref. '22' ** Obsolete normative reference: RFC 2233 (ref. '23') (Obsoleted by RFC 2863) ** Obsolete normative reference: RFC 1825 (ref. '24') (Obsoleted by RFC 2401) ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '25') Summary: 29 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Dave Thaler 3 INTERNET-DRAFT Microsoft 4 Expires January 1999 27 July 1998 6 IP Tunnel MIB 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 23 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 Copyright Notice 28 Copyright (C) The Internet Society (1998). All Rights Reserved. 30 1. Introduction 32 This memo defines an experimental portion of the Management Information 33 Base (MIB) for use with network management protocols in the Internet 34 community. In particular, it describes managed objects used for 35 managing tunnels of any type in IP networks, including GRE [16,17], IP- 36 in-IP [18], Minimal Encapsulation [19], L2TP [20], L2F [25], and PPTP 37 [21] tunnels. Extension MIBs (e.g., [22]) may be designed for managing 38 protocol-specific objects. Likewise, extension MIBs may be designed for 39 Draft IP Tunnel MIB July 1998 41 managing security-specific objects (e.g., IPSEC [24]). 43 2. Revision History 45 A record of changes which will be removed before publication. 47 27 July 1998 49 (1) Added tunnel config table to improve support for dynamic tunnel 50 creation. 52 (2) Added L2F as an encapsulation method. 54 (3) Added Security Considerations and copyright notice, and updated 55 SNMP Framework text and references. 57 18 April 1997 59 (1) initial version. 61 3. The SNMPv2 Network Management Framework 63 The SNMP Management Framework presently consists of five major 64 components: 66 o An overall architecture, described in RFC 2271 [1]. 68 o Mechanisms for describing and naming objects and events for the 69 purpose of management. The first version of this Structure of 70 Management Information (SMI) is called SMIv1 and described in RFC 71 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called 72 SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. 74 o Message protocols for transferring management information. The 75 first version of the SNMP message protocol is called SNMPv1 and 76 described in RFC 1157 [8]. A second version of the SNMP message 77 protocol, which is not an Internet standards track protocol, is 78 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 79 The third version of the message protocol is called SNMPv3 and 80 described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 82 o Protocol operations for accessing management information. The first 83 set of protocol operations and associated PDU formats is described 85 Draft IP Tunnel MIB July 1998 87 in RFC 1157 [8]. A second set of protocol operations and associated 88 PDU formats is described in RFC 1905 [13]. 90 o A set of fundamental applications described in RFC 2273 [14] and 91 the view-based access control mechanism described in RFC 2275 [15]. 93 Managed objects are accessed via a virtual information store, termed the 94 Management Information Base or MIB. Objects in the MIB are defined 95 using the mechanisms defined in the SMI. 97 This memo specifies a MIB module that is compliant to the SMIv2. A MIB 98 conforming to the SMIv1 can be produced through the appropriate 99 translations. The resulting translated MIB must be semantically 100 equivalent, except where objects or events are omitted because no 101 translation is possible (use of Counter64). Some machine readable 102 information in SMIv2 will be converted into textual descriptions in 103 SMIv1 during the translation process. However, this loss of machine 104 readable information is not considered to change the semantics of the 105 MIB. 107 3.1. Object Definitions 109 Managed objects are accessed via a virtual information store, termed the 110 Management Information Base or MIB. Objects in the MIB are defined 111 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 112 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 113 an administratively assigned name. The object type together with an 114 object instance serves to uniquely identify a specific instantiation of 115 the object. For human convenience, we often use a textual string, 116 termed the descriptor, to refer to the object type. 118 4. Overview 120 This MIB module contains two tables: 122 o the Tunnel Interface Table, containing information on the tunnels 123 known to a router; and 125 o the Tunnel Config Table, which is used for dynamic creation of 126 tunnels. 128 Draft IP Tunnel MIB July 1998 130 4.1. Relationship to the Interfaces MIB 132 This section clarifies the relationship of this MIB to the Interfaces 133 MIB [23]. Several areas of correlation are addressed in the following 134 subsections. The implementor is referred to the Interfaces MIB document 135 in order to understand the general intent of these areas. 137 4.1.1. Layering Model 139 Each logical interface (physical or virtual) has an ifEntry in the 140 Interfaces MIB [23]. Tunnels are handled by creating a logical 141 interface (ifEntry) for each tunnel. These are then correlated to 142 physical interfaces using the ifStack table of the Interfaces MIB. The 143 basic model, therefore, looks something like this (for example): 145 | | | | | | 146 +--+ +---+ +--+ +---+ | | 147 |IP-in-IP| | GRE | | | 148 | tunnel | | tunnel | | | 149 +--+ +---+ +--+ +---+ | | 150 | | | | | | <== attachment to physical 151 +--+ +---------+ +----------+ +--+ interfaces, to be provided 152 | Physical interface | by ifStack table 153 +--------------------------------+ 155 4.1.2. ifTestTable 157 The ifTestTable usage is defined in the MIBs defining the 158 encapsulation below the network layer. For example, if IP-in-IP 159 encapsulation is being used, the ifTestTable is defined by IP-in-IP. 161 4.1.3. ifRcvAddressTable 163 The ifRcvAddressTable usage is defined in the MIBs defining the 164 encapsulation below the network layer. For example, if IP-in-IP 165 encapsulation is being used, the ifRcvAddressTable is defined by IP- 166 in-IP. 168 Draft IP Tunnel MIB July 1998 170 4.1.4. ifEntry 172 IfEntries are defined in the MIBs defining the encapsulation below 173 the network layer. For example, if IP-in-IP encapsulation [20] is 174 being used, the ifEntry is defined by IP-in-IP. 176 The ifType of a tunnel should be set to "tunnel" (131). An entry in 177 the IP Tunnel MIB will exist for every ifEntry with this ifType. An 178 implementation of the IP Tunnel MIB MAY allow ifEntries to be created 179 via the tunnelConfigTable. Creating a tunnel will also add an entry 180 in the ifTable and in the tunnelIfTable, and deleting a tunnel will 181 likewise delete the entry in the ifTable and the tunnelIfTable. 183 The use of two different tables in this MIB was an important design 184 decision. Traditionally, ifIndex values are chosen by agents, and 185 are permitted to change across restarts. Allowing row creation 186 directly in the Tunnel Interface Table, indexed by ifIndex, would 187 complicate row creation and/or cause interoperability problems (if 188 each agent had special restrictions on ifIndex). Instead, a separate 189 table is used which is indexed only by objects over which the manager 190 has control. Namely, these are the addresses of the tunnel endpoints 191 and the encapsulation protocol. Finally, an additional manager- 192 chosen ID is used in the index to support protocols such as L2F which 193 allow multiple tunnels between the same endpoints. 195 Draft IP Tunnel MIB July 1998 197 5. Definitions 199 TUNNEL-MIB DEFINITIONS ::= BEGIN 201 IMPORTS 202 MODULE-IDENTITY, OBJECT-TYPE, transmission, 203 Integer32, IpAddress FROM SNMPv2-SMI 204 RowStatus FROM SNMPv2-TC 205 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 206 ifIndex FROM IF-MIB; 208 tunnelMIB MODULE-IDENTITY 209 LAST-UPDATED "9807271200Z" 210 ORGANIZATION "Microsoft Corporation" 211 CONTACT-INFO 212 " Dave Thaler 213 Microsoft Corporation 214 One Microsoft Way 215 Redmond, WA 98052-6399 216 EMail: dthalerd@microsoft.com" 217 DESCRIPTION 218 "The MIB module for management of IP Tunnels, independent of 219 the specific encapsulation scheme in use." 220 ::= { transmission 131 } 222 tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 } 224 tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 } 225 Draft IP Tunnel MIB July 1998 227 -- the IP Tunnel MIB-Group 228 -- 229 -- a collection of objects providing information about 230 -- IP Tunnels 232 tunnelIfTable OBJECT-TYPE 233 SYNTAX SEQUENCE OF TunnelIfEntry 234 MAX-ACCESS not-accessible 235 STATUS current 236 DESCRIPTION 237 "The (conceptual) table containing information on configured 238 tunnels." 239 ::= { tunnel 1 } 241 tunnelIfEntry OBJECT-TYPE 242 SYNTAX TunnelIfEntry 243 MAX-ACCESS not-accessible 244 STATUS current 245 DESCRIPTION 246 "An entry (conceptual row) containing the information on a 247 particular configured tunnel." 248 INDEX { ifIndex } 249 ::= { tunnelIfTable 1 } 251 TunnelIfEntry ::= SEQUENCE { 252 tunnelIfLocalAddress IpAddress, 253 tunnelIfRemoteAddress IpAddress, 254 tunnelIfEncapsMethod INTEGER, 255 tunnelIfHopLimit Integer32, 256 tunnelIfPriority Integer32, 257 tunnelIfEncapsLimit Integer32, 258 tunnelIfSecurity INTEGER 259 } 261 tunnelIfLocalAddress OBJECT-TYPE 262 SYNTAX IpAddress 263 MAX-ACCESS read-only 264 STATUS current 265 DESCRIPTION 266 "The address of the local endpoint of the tunnel, or 0.0.0.0 267 if unknown." 268 ::= { tunnelIfEntry 1 } 270 tunnelIfRemoteAddress OBJECT-TYPE 271 Draft IP Tunnel MIB July 1998 273 SYNTAX IpAddress 274 MAX-ACCESS read-only 275 STATUS current 276 DESCRIPTION 277 "The address of the remote endpoint of the tunnel, or 278 0.0.0.0 if unknown." 279 ::= { tunnelIfEntry 2 } 281 tunnelIfEncapsMethod OBJECT-TYPE 282 SYNTAX INTEGER { 283 other(1), -- none of the following 284 native(2), -- no intermediate header 285 gre(3), -- GRE encapsulation 286 minimal(4), -- Minimal encapsulation 287 l2tp(5), -- L2TP encapsulation 288 pptp(6), -- PPTP encapsulation 289 l2f(7) -- L2F encapsulation 290 } 291 MAX-ACCESS read-only 292 STATUS current 293 DESCRIPTION 294 "The encapsulation method used by the tunnel. The value 295 native indicates that the packet is encapsulated inside a 296 normal IPv4 header and unicast to the remote tunnel 297 endpoint. The value gre indicates that a GRE header is 298 inserted between the outer header and the payload header, 299 and minimal indicates that a Minimal Forwarding Header (RFC 300 2004) is inserted between the outer header and the payload 301 data. The value pptp indicates that an enhanced GRE header 302 and a PPP header are inserted." 303 ::= { tunnelIfEntry 3 } 305 tunnelIfHopLimit OBJECT-TYPE 306 SYNTAX Integer32 (0..255) 307 MAX-ACCESS read-create 308 STATUS current 309 DESCRIPTION 310 "The IPv4 TTL (or IPv6 hop limit) to use in the outer IP 311 header. A value of 0 indicates that the value is copied from 312 the payload's header." 313 ::= { tunnelIfEntry 4 } 315 tunnelIfPriority OBJECT-TYPE 316 SYNTAX Integer32 (-1..15) 317 MAX-ACCESS read-create 319 Draft IP Tunnel MIB July 1998 321 STATUS current 322 DESCRIPTION 323 "The IPv4 Preference or IPv6 Priority to use in the outer IP 324 header. A value of -1 indicates that the value is copied 325 from the payload's header." 326 ::= { tunnelIfEntry 6 } 328 tunnelIfEncapsLimit OBJECT-TYPE 329 SYNTAX Integer32 330 MAX-ACCESS read-create 331 STATUS current 332 DESCRIPTION 333 "The maximum number of encapsulations permitted for packets 334 undergoing encapsulation at this node. A value of 0 335 indicates that no limit is present (except as a result of 336 the packet size)." 337 ::= { tunnelIfEntry 7 } 339 tunnelIfSecurity OBJECT-TYPE 340 SYNTAX INTEGER { 341 none(1), -- no security 342 ipsec(2), -- IPSEC security 343 other(3) 344 } 345 MAX-ACCESS read-only 346 STATUS current 347 DESCRIPTION 348 "The method used by the tunnel to secure the outer IP 349 header." 350 ::= { tunnelIfEntry 8 } 352 tunnelConfigTable OBJECT-TYPE 353 SYNTAX SEQUENCE OF TunnelConfigEntry 354 MAX-ACCESS not-accessible 355 STATUS current 356 DESCRIPTION 357 "The (conceptual) table containing information on configured 358 tunnels. This table can be used to map a set of tunnel 359 endpoints to the associated ifIndex value. It can also be 360 used for row creation." 361 ::= { tunnel 2 } 363 tunnelConfigEntry OBJECT-TYPE 364 SYNTAX TunnelConfigEntry 365 MAX-ACCESS not-accessible 367 Draft IP Tunnel MIB July 1998 369 STATUS current 370 DESCRIPTION 371 "An entry (conceptual row) containing the information on a 372 particular configured tunnel." 373 INDEX { tunnelConfigLocalAddress, 374 tunnelConfigRemoteAddress, 375 tunnelConfigEncapsMethod, 376 tunnelConfigID } 377 ::= { tunnelConfigTable 1 } 379 TunnelConfigEntry ::= SEQUENCE { 380 tunnelConfigLocalAddress IpAddress, 381 tunnelConfigRemoteAddress IpAddress, 382 tunnelConfigEncapsMethod INTEGER, 383 tunnelConfigID Integer32, 384 tunnelConfigIfIndex Integer32, 385 tunnelConfigStatus RowStatus 386 } 388 tunnelConfigLocalAddress OBJECT-TYPE 389 SYNTAX IpAddress 390 MAX-ACCESS not-accessible 391 STATUS current 392 DESCRIPTION 393 "The address of the local endpoint of the tunnel, or 0.0.0.0 394 if unknown." 395 ::= { tunnelConfigEntry 1 } 397 tunnelConfigRemoteAddress OBJECT-TYPE 398 SYNTAX IpAddress 399 MAX-ACCESS not-accessible 400 STATUS current 401 DESCRIPTION 402 "The address of the remote endpoint of the tunnel, or 403 0.0.0.0 if unknown." 404 ::= { tunnelConfigEntry 2 } 406 tunnelConfigEncapsMethod OBJECT-TYPE 407 SYNTAX INTEGER { 408 other(1), -- none of the following 409 native(2), -- no intermediate header 410 gre(3), -- GRE encapsulation 411 minimal(4), -- Minimal encapsulation 412 l2tp(5), -- L2TP encapsulation 413 pptp(6), -- PPTP encapsulation 415 Draft IP Tunnel MIB July 1998 417 l2f(7) -- L2F encapsulation 418 } 419 MAX-ACCESS not-accessible 420 STATUS current 421 DESCRIPTION 422 "The encapsulation method used by the tunnel." 423 ::= { tunnelConfigEntry 3 } 425 tunnelConfigID OBJECT-TYPE 426 SYNTAX Integer32 427 MAX-ACCESS not-accessible 428 STATUS current 429 DESCRIPTION 430 "An identifier used to distinguish between multiple tunnels 431 of the same encapsulation method, with the same endpoints. 432 If the encapsulation protocol only allows one tunnel per set 433 of endpoint addresses (such as for GRE or IP-in-IP), the 434 value of this object is 1. For encapsulation methods (such 435 as L2F) which allow multiple parallel tunnels, the manager 436 is responsible for choosing any ID which does not conflict 437 with an existing row, such as choosing a random number." 438 ::= { tunnelConfigEntry 4 } 440 tunnelConfigIfIndex OBJECT-TYPE 441 SYNTAX Integer32 442 MAX-ACCESS read-only 443 STATUS current 444 DESCRIPTION 445 "The value of ifIndex corresponding to the tunnel 446 interface." 447 ::= { tunnelConfigEntry 5 } 449 tunnelConfigStatus OBJECT-TYPE 450 SYNTAX RowStatus 451 MAX-ACCESS read-create 452 STATUS current 453 DESCRIPTION 454 "The status of this row, by which new entries may be 455 created, or old entries deleted from this table. Creating a 456 row in this table will create a corresponding row in the 457 ifTable and in the tunnelIfTable. Deleting a row in this 458 table will likewise delete the corresponding row in the 459 ifTable and in the tunnelIfTable." 460 ::= { tunnelConfigEntry 6 } 462 Draft IP Tunnel MIB July 1998 464 -- conformance information 466 tunnelMIBConformance 467 OBJECT IDENTIFIER ::= { tunnelMIB 2 } 468 tunnelMIBCompliances 469 OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 } 470 tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 } 472 -- compliance statements 474 tunnelMIBCompliance MODULE-COMPLIANCE 475 STATUS current 476 DESCRIPTION 477 "The compliance statement for the IP Tunnel MIB." 478 MODULE -- this module 479 MANDATORY-GROUPS { tunnelMIBBasicGroup } 481 OBJECT tunnelIfHopLimit 482 MIN-ACCESS read-only 483 DESCRIPTION 484 "Write access is not required." 486 OBJECT tunnelIfPriority 487 MIN-ACCESS read-only 488 DESCRIPTION 489 "Write access is not required." 491 OBJECT tunnelIfEncapsLimit 492 MIN-ACCESS read-only 493 DESCRIPTION 494 "Write access is not required." 496 OBJECT tunnelConfigStatus 497 MIN-ACCESS read-only 498 DESCRIPTION 499 "Write access is not required." 500 ::= { tunnelMIBCompliances 1 } 502 -- units of conformance 504 tunnelMIBBasicGroup OBJECT-GROUP 505 OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress, 506 tunnelIfEncapsMethod, tunnelIfHopLimit, 507 tunnelIfPriority, tunnelIfEncapsLimit, tunnelIfSecurity, 509 Draft IP Tunnel MIB July 1998 511 tunnelConfigIfIndex, tunnelConfigStatus } 512 STATUS current 513 DESCRIPTION 514 "A collection of objects to support basic management of IP 515 Tunnels." 516 ::= { tunnelMIBGroups 1 } 518 END 519 Draft IP Tunnel MIB July 1998 521 6. Security Considerations 523 This MIB contains readable objects whose values provide information 524 related to IP tunnel interfaces. There are also a number of objects 525 that have a MAX-ACCESS clause of read-write and/or read-create, such as 526 those which allow an administrator to dynamically configure tunnels. 528 While unauthorized access to the readable objects is relatively 529 innocuous, unauthorized access to the write-able objects could cause a 530 denial of service, or could cause unauthorized creation and/or 531 manipulation of tunnels. Hence, the support for SET operations in a 532 non-secure environment without proper protection can have a negative 533 effect on network operations. 535 SNMPv1 by itself is such an insecure environment. Even if the network 536 itself is secure (for example by using IPSec [24]), even then, there is 537 no control as to who on the secure network is allowed to access and SET 538 (change/create/delete) the objects in this MIB. 540 It is recommended that the implementers consider the security features 541 as provided by the SNMPv3 framework. Specifically, the use of the 542 User-based Security Model RFC 2274 [12] and the View-based Access 543 Control Model RFC 2275 [15] is recommended. 545 It is then a customer/user responsibility to ensure that the SNMP entity 546 giving access to this MIB, is properly configured to give access to 547 those objects only to those principals (users) that have legitimate 548 rights to access them. 550 7. Acknowledgements 552 This MIB module was updated based on feedback from the IETF's Interfaces 553 MIB (IF-MIB) and Point-to-Point Protocol Extensions (PPPEXT) Working 554 Groups. 556 8. Author's Address 558 Dave Thaler 559 Microsoft Corporation 560 One Microsoft Way 561 Redmond, WA 48105-6399 562 Phone: +1 425 703 8835 563 EMail: dthaler@microsoft.com 565 Draft IP Tunnel MIB July 1998 567 9. References 569 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 570 Describing SNMP Management Frameworks", RFC 2271, Cabletron 571 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 572 January 1998. 574 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 575 Management Information for TCP/IP-based Internets", RFC 1155, 576 Performance Systems International, Hughes LAN Systems, May 1990. 578 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 579 Performance Systems International, Hughes LAN Systems, March 1991. 581 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 582 RFC 1215, Performance Systems International, March 1991. 584 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 585 of Management Information for Version 2 of the Simple Network 586 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco 587 Systems, Inc., Dover Beach Consulting, Inc., International Network 588 Services, January 1996. 590 [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 591 Conventions for Version 2 of the Simple Network Management Protocol 592 (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., 593 Dover Beach Consulting, Inc., International Network Services, 594 January 1996. 596 [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 597 Statements for Version 2 of the Simple Network Management Protocol 598 (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., 599 Dover Beach Consulting, Inc., International Network Services, 600 January 1996. 602 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 603 Management Protocol", RFC 1157, SNMP Research, Performance Systems 604 International, Performance Systems International, MIT Laboratory 605 for Computer Science, May 1990. 607 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 608 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 609 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 610 International Network Services, January 1996. 612 Draft IP Tunnel MIB July 1998 614 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 615 Mappings for Version 2 of the Simple Network Management Protocol 616 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 617 Dover Beach Consulting, Inc., International Network Services, 618 January 1996. 620 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 621 Processing and Dispatching for the Simple Network Management 622 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 623 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 625 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 626 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 627 2274, IBM T. J. Watson Research, January 1998. 629 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 630 Operations for Version 2 of the Simple Network Management Protocol 631 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 632 Dover Beach Consulting, Inc., International Network Services, 633 January 1996. 635 [14] Levi, D., Meyer, P., and B. Stewart, "MPv3 Applications", RFC 2273, 636 SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, 637 January 1998. 639 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 640 Control Model (VACM) for the Simple Network Management Protocol 641 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 642 Cisco Systems, Inc., January 1998. 644 [16] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing 645 Encapsulation (GRE)", RFC 1701, October 1994. 647 [17] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing 648 Encapsulation over IPv4 networks", RFC 1702, October 1994. 650 [18] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. 652 [19] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 653 1996. 655 [20] Hamzeh, Kolar, Littlewood, Pall, Taarud, Valencia, and Verthein, 656 "Layer Two Tunneling Protocol (L2TP)", draft-ietf-pppext-l2tp- 657 04.txt, June 1997. 659 Draft IP Tunnel MIB July 1998 661 [21] Hamzeh, Pall, Verthein, Taarud, and Little, "Point-to-Point 662 Tunneling Protocol--PPTP", draft-ietf-pppext-pptp-02.txt, July 663 1997. 665 [22] Calhoun, Reddy, Vroman, and Wheeler. "Layer Two Tunneling Protocol 666 "L2TP" Management Information Base", draft-ietf-pppext-l2tp-mib- 667 00.txt, October 1997. 669 [23] McCloghrie, K., and F. Kastenholz. "The Interfaces Group MIB using 670 SMIv2", RFC 2233, November 1997. 672 [24] R. Atkinson. "Security architecture for the internet protocol", 673 RFC 1825, August 1995. 675 [25] Valencia, A., Littlewood, M., and T. Kolar. "Cisco Layer Two 676 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 678 10. Full Copyright Statement 680 Copyright (C) The Internet Society (1998). All Rights Reserved. 682 This document and translations of it may be copied and furnished to 683 others, and derivative works that comment on or otherwise explain it or 684 assist in its implmentation may be prepared, copied, published and 685 distributed, in whole or in part, without restriction of any kind, 686 provided that the above copyright notice and this paragraph are included 687 on all such copies and derivative works. However, this document itself 688 may not be modified in any way, such as by removing the copyright notice 689 or references to the Internet Society or other Internet organizations, 690 except as needed for the purpose of developing Internet standards in 691 which case the procedures for copyrights defined in the Internet 692 Standards process must be followed, or as required to translate it into 693 languages other than English. 695 The limited permissions granted above are perpetual and will not be 696 revoked by the Internet Society or its successors or assigns. 698 This document and the information contained herein is provided on an "AS 699 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 700 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 701 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 702 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 703 FITNESS FOR A PARTICULAR PURPOSE." 704 Draft IP Tunnel MIB July 1998 706 Table of Contents 708 1 Introduction .................................................... 1 709 2 Revision History ................................................ 2 710 3 The SNMPv2 Network Management Framework ......................... 2 711 3.1 Object Definitions ............................................ 3 712 4 Overview ........................................................ 3 713 4.1 Relationship to the Interfaces MIB ............................ 4 714 4.1.1 Layering Model .............................................. 4 715 4.1.2 ifTestTable ................................................. 4 716 4.1.3 ifRcvAddressTable ........................................... 4 717 4.1.4 ifEntry ..................................................... 5 718 5 Definitions ..................................................... 6 719 6 Security Considerations ......................................... 14 720 7 Acknowledgements ................................................ 14 721 8 Author's Address ................................................ 14 722 9 References ...................................................... 15 723 10 Full Copyright Statement ....................................... 17