idnits 2.17.00 (12 Aug 2021) /tmp/idnits27068/draft-ietf-ifmib-tunnel-mib-06.txt: ** The Abstract section seems to be numbered 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. 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 (15 June 1999) is 8369 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 2571 (ref. '1') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** 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 2572 (ref. '11') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '12') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '14') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '15') (Obsoleted by RFC 3415) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '16') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '17') -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '22') ** Obsolete normative reference: RFC 2233 (ref. '23') (Obsoleted by RFC 2863) ** Obsolete normative reference: RFC 2401 (ref. '24') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '25') ** Downref: Normative reference to an Historic RFC: RFC 1234 (ref. '26') ** Obsolete normative reference: RFC 1933 (ref. '27') (Obsoleted by RFC 2893) ** Downref: Normative reference to an Experimental RFC: RFC 1241 (ref. '28') Summary: 24 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IFMIB Working Group Dave Thaler 2 INTERNET-DRAFT Microsoft 3 Expires December 1999 15 June 1999 5 IP Tunnel MIB 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (1999). All Rights Reserved. 32 1. Abstract 34 This memo defines a Management Information Base (MIB) for use with 35 network management protocols in the Internet community. In particular, 36 it describes managed objects used for managing tunnels of any type over 37 IPv4 networks. Extension MIBs may be designed for managing protocol- 38 specific objects. Likewise, extension MIBs may be designed for managing 39 security-specific objects. This MIB does not support tunnels over non- 40 IPv4 networks (including IPv6 networks). Management of such tunnels may 41 be supported by other MIBs. 43 2. Introduction 45 Over the past several years, there have been a number of "tunneling" 46 protocols specified by the IETF (see [28] for an early discussion of the 47 model and examples). This document describes a Management Information 48 Base (MIB) used for managing tunnels of any type over IPv4 networks, 49 including GRE [16,17], IP-in-IP [18], Minimal Encapsulation [19], L2TP 50 [20], PPTP [21], L2F [25], UDP (e.g., [26]), ATMP [22], and IPv6-in-IPv4 51 [27] tunnels. 53 Extension MIBs may be designed for managing protocol-specific objects. 54 Likewise, extension MIBs may be designed for managing security-specific 55 objects (e.g., IPSEC [24]), and traffic conditioner [29] objects. 56 Finally, this MIB does not support tunnels over non-IPv4 networks 57 (including IPv6 networks). Management of such tunnels may be supported 58 by other MIBs. 60 3. The SNMP Network Management Framework 62 The SNMP Management Framework presently consists of five major 63 components: 65 o An overall architecture, described in RFC 2571 [1]. 67 o Mechanisms for describing and naming objects and events for the 68 purpose of management. The first version of this Structure of 69 Management Information (SMI) is called SMIv1 and described in RFC 70 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called 71 SMIv2, is described in RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. 73 o Message protocols for transferring management information. The 74 first version of the SNMP message protocol is called SNMPv1 and 75 described in RFC 1157 [8]. A second version of the SNMP message 76 protocol, which is not an Internet standards track protocol, is 77 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 78 The third version of the message protocol is called SNMPv3 and 79 described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. 81 o Protocol operations for accessing management information. The first 82 set of protocol operations and associated PDU formats is described 83 in RFC 1157 [8]. A second set of protocol operations and associated 84 PDU formats is described in RFC 1905 [13]. 86 o A set of fundamental applications described in RFC 2573 [14] and 87 the view-based access control mechanism described in RFC 2575 [15]. 89 Managed objects are accessed via a virtual information store, termed the 90 Management Information Base or MIB. Objects in the MIB are defined 91 using the mechanisms defined in the SMI. 93 This memo specifies a MIB module that is compliant to the SMIv2. A MIB 94 conforming to the SMIv1 can be produced through the appropriate 95 translations. The resulting translated MIB must be semantically 96 equivalent, except where objects or events are omitted because no 97 translation is possible (use of Counter64). Some machine readable 98 information in SMIv2 will be converted into textual descriptions in 99 SMIv1 during the translation process. However, this loss of machine 100 readable information is not considered to change the semantics of the 101 MIB. 103 4. Overview 105 This MIB module contains two tables: 107 o the Tunnel Interface Table, containing information on the tunnels 108 known to a router; and 110 o the Tunnel Config Table, which can be used for dynamic creation of 111 tunnels, and also provides a mapping from endpoint addresses to the 112 current interface index value. 114 4.1. Relationship to the Interfaces MIB 116 This section clarifies the relationship of this MIB to the Interfaces 117 MIB [23]. Several areas of correlation are addressed in the following 118 subsections. The implementor is referred to the Interfaces MIB document 119 in order to understand the general intent of these areas. 121 4.1.1. Layering Model 123 Each logical interface (physical or virtual) has an ifEntry in the 124 Interfaces MIB [23]. Tunnels are handled by creating a logical 125 interface (ifEntry) for each tunnel. These are then correlated, using 126 the ifStack table of the Interfaces MIB, to those interfaces on which 127 the local IPv4 addresses of the tunnels are configured. The basic 128 model, therefore, looks something like this (for example): 130 | | | | | | 131 +--+ +---+ +--+ +---+ | | 132 |IP-in-IP| | GRE | | | 133 | tunnel | | tunnel | | | 134 +--+ +---+ +--+ +---+ | | 135 | | | | | | <== attachment to underlying 136 +--+ +---------+ +----------+ +--+ interfaces, to be provided 137 | Physical interface | by ifStack table 138 +--------------------------------+ 140 4.1.2. ifRcvAddressTable 142 The ifRcvAddressTable usage is defined in the MIBs defining the 143 encapsulation below the network layer. For example, if IP-in-IP 144 encapsulation is being used, the ifRcvAddressTable is defined by IP- 145 in-IP. 147 4.1.3. ifEntry 149 IfEntries are defined in the MIBs defining the encapsulation below 150 the network layer. For example, if IP-in-IP encapsulation [20] is 151 being used, the ifEntry is defined by IP-in-IP. 153 The ifType of a tunnel should be set to "tunnel" (131). An entry in 154 the IP Tunnel MIB will exist for every ifEntry with this ifType. An 155 implementation of the IP Tunnel MIB may allow ifEntries to be created 156 via the tunnelConfigTable. Creating a tunnel will also add an entry 157 in the ifTable and in the tunnelIfTable, and deleting a tunnel will 158 likewise delete the entry in the ifTable and the tunnelIfTable. 160 The use of two different tables in this MIB was an important design 161 decision. Traditionally, ifIndex values are chosen by agents, and 162 are permitted to change across restarts. Allowing row creation 163 directly in the Tunnel Interface Table, indexed by ifIndex, would 164 complicate row creation and/or cause interoperability problems (if 165 each agent had special restrictions on ifIndex). Instead, a separate 166 table is used which is indexed only by objects over which the manager 167 has control. Namely, these are the addresses of the tunnel endpoints 168 and the encapsulation protocol. Finally, an additional manager- 169 chosen ID is used in the index to support protocols such as L2F which 170 allow multiple tunnels between the same endpoints. 172 5. Definitions 174 TUNNEL-MIB DEFINITIONS ::= BEGIN 176 IMPORTS 177 MODULE-IDENTITY, OBJECT-TYPE, transmission, 178 Integer32, IpAddress FROM SNMPv2-SMI 179 RowStatus FROM SNMPv2-TC 180 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 181 ifIndex, InterfaceIndexOrZero FROM IF-MIB; 183 tunnelMIB MODULE-IDENTITY 184 LAST-UPDATED "9906151200Z" -- June 15, 1999 185 ORGANIZATION "IETF Interfaces MIB Working Group" 186 CONTACT-INFO 187 " Dave Thaler 188 Microsoft Corporation 189 One Microsoft Way 190 Redmond, WA 98052-6399 191 EMail: dthaler@dthaler.microsoft.com" 192 DESCRIPTION 193 "The MIB module for management of IP Tunnels, independent of 194 the specific encapsulation scheme in use." 195 REVISION "9906151200Z" -- June 15, 1999 196 DESCRIPTION 197 "Initial version, published as RFC xxxx (to be filled in by 198 RFC-Editor)." 199 ::= { transmission 131 } 201 tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 } 203 tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 } 204 -- the IP Tunnel MIB-Group 205 -- 206 -- a collection of objects providing information about 207 -- IP Tunnels 209 tunnelIfTable OBJECT-TYPE 210 SYNTAX SEQUENCE OF TunnelIfEntry 211 MAX-ACCESS not-accessible 212 STATUS current 213 DESCRIPTION 214 "The (conceptual) table containing information on configured 215 tunnels." 216 ::= { tunnel 1 } 218 tunnelIfEntry OBJECT-TYPE 219 SYNTAX TunnelIfEntry 220 MAX-ACCESS not-accessible 221 STATUS current 222 DESCRIPTION 223 "An entry (conceptual row) containing the information on a 224 particular configured tunnel." 225 INDEX { ifIndex } 226 ::= { tunnelIfTable 1 } 228 TunnelIfEntry ::= SEQUENCE { 229 tunnelIfLocalAddress IpAddress, 230 tunnelIfRemoteAddress IpAddress, 231 tunnelIfEncapsMethod INTEGER, 232 tunnelIfHopLimit Integer32, 233 tunnelIfSecurity INTEGER, 234 tunnelIfTOS Integer32 235 } 237 tunnelIfLocalAddress OBJECT-TYPE 238 SYNTAX IpAddress 239 MAX-ACCESS read-only 240 STATUS current 241 DESCRIPTION 242 "The address of the local endpoint of the tunnel (i.e., the 243 source address used in the outer IP header), or 0.0.0.0 if 244 unknown." 245 ::= { tunnelIfEntry 1 } 247 tunnelIfRemoteAddress OBJECT-TYPE 248 SYNTAX IpAddress 249 MAX-ACCESS read-only 250 STATUS current 251 DESCRIPTION 252 "The address of the remote endpoint of the tunnel (i.e., the 253 destination address used in the outer IP header), or 0.0.0.0 254 if unknown." 255 ::= { tunnelIfEntry 2 } 257 tunnelIfEncapsMethod OBJECT-TYPE 258 SYNTAX INTEGER { 259 other(1), -- none of the following 260 direct(2), -- no intermediate header 261 gre(3), -- GRE encapsulation 262 minimal(4), -- Minimal encapsulation 263 l2tp(5), -- L2TP encapsulation 264 pptp(6), -- PPTP encapsulation 265 l2f(7), -- L2F encapsulation 266 udp(8), -- UDP encapsulation 267 atmp(9) -- ATMP encapsulation 268 } 269 MAX-ACCESS read-only 270 STATUS current 271 DESCRIPTION 272 "The encapsulation method used by the tunnel. The value 273 direct indicates that the packet is encapsulated directly 274 within a normal IPv4 header, with no intermediate header, 275 and unicast to the remote tunnel endpoint (e.g., an RFC 2003 276 IP-in-IP tunnel, or an RFC 1933 IPv6-in-IPv4 tunnel). The 277 value minimal indicates that a Minimal Forwarding Header 278 (RFC 2004) is inserted between the outer header and the 279 payload packet. The value UDP indicates that the payload 280 packet is encapsulated within a normal UDP packet (e.g., RFC 281 1234). The remaining protocol-specific values indicate that 282 a header of the protocol of that name is inserted between 283 the outer header and the payload header." 284 ::= { tunnelIfEntry 3 } 286 tunnelIfHopLimit OBJECT-TYPE 287 SYNTAX Integer32 (0..255) 288 MAX-ACCESS read-write 289 STATUS current 290 DESCRIPTION 291 "The TTL to use in the outer IP header. A value of 0 292 indicates that the value is copied from the payload's 293 header." 294 ::= { tunnelIfEntry 4 } 296 tunnelIfSecurity OBJECT-TYPE 297 SYNTAX INTEGER { 298 none(1), -- no security 299 ipsec(2), -- IPSEC security 300 other(3) 301 } 302 MAX-ACCESS read-only 303 STATUS current 304 DESCRIPTION 305 "The method used by the tunnel to secure the outer IP 306 header. The value ipsec indicates that IPsec is used 307 between the tunnel endpoints for authentication or 308 encryption or both. More specific security-related 309 information may be available in a MIB for the security 310 protocol in use." 311 ::= { tunnelIfEntry 5 } 313 tunnelIfTOS OBJECT-TYPE 314 SYNTAX Integer32 (-2..63) 315 MAX-ACCESS read-write 316 STATUS current 317 DESCRIPTION 318 "The method used to set the high 6 bits of the TOS in the 319 outer IP header. A value of -1 indicates that the bits are 320 copied from the payload's header. A value of -2 indicates 321 that a traffic conditioner is invoked and more information 322 may be available in a traffic conditioner MIB. A value 323 between 0 and 63 inclusive indicates that the bit field is 324 set to the indicated value." 325 ::= { tunnelIfEntry 6 } 327 tunnelConfigTable OBJECT-TYPE 328 SYNTAX SEQUENCE OF TunnelConfigEntry 329 MAX-ACCESS not-accessible 330 STATUS current 331 DESCRIPTION 332 "The (conceptual) table containing information on configured 333 tunnels. This table can be used to map a set of tunnel 334 endpoints to the associated ifIndex value. It can also be 335 used for row creation. Note that every row in the 336 tunnelIfTable with a fixed destination address should have a 337 corresponding row in the tunnelConfigTable, regardless of 338 whether it was created via SNMP." 339 ::= { tunnel 2 } 341 tunnelConfigEntry OBJECT-TYPE 342 SYNTAX TunnelConfigEntry 343 MAX-ACCESS not-accessible 344 STATUS current 345 DESCRIPTION 346 "An entry (conceptual row) containing the information on a 347 particular configured tunnel." 348 INDEX { tunnelConfigLocalAddress, 349 tunnelConfigRemoteAddress, 350 tunnelConfigEncapsMethod, 351 tunnelConfigID } 352 ::= { tunnelConfigTable 1 } 354 TunnelConfigEntry ::= SEQUENCE { 355 tunnelConfigLocalAddress IpAddress, 356 tunnelConfigRemoteAddress IpAddress, 357 tunnelConfigEncapsMethod INTEGER, 358 tunnelConfigID Integer32, 359 tunnelConfigIfIndex InterfaceIndexOrZero, 360 tunnelConfigStatus RowStatus 361 } 363 tunnelConfigLocalAddress OBJECT-TYPE 364 SYNTAX IpAddress 365 MAX-ACCESS not-accessible 366 STATUS current 367 DESCRIPTION 368 "The address of the local endpoint of the tunnel, or 0.0.0.0 369 if the device is free to choose any of its addresses at 370 tunnel establishment time." 371 ::= { tunnelConfigEntry 1 } 373 tunnelConfigRemoteAddress OBJECT-TYPE 374 SYNTAX IpAddress 375 MAX-ACCESS not-accessible 376 STATUS current 377 DESCRIPTION 378 "The address of the remote endpoint of the tunnel." 379 ::= { tunnelConfigEntry 2 } 381 tunnelConfigEncapsMethod OBJECT-TYPE 382 SYNTAX INTEGER { 383 other(1), -- none of the following 384 direct(2), -- no intermediate header 385 gre(3), -- GRE encapsulation 386 minimal(4), -- Minimal encapsulation 387 l2tp(5), -- L2TP encapsulation 388 pptp(6), -- PPTP encapsulation 389 l2f(7), -- L2F encapsulation 390 udp(8), -- UDP encapsulation 391 atmp(9) 392 } 393 MAX-ACCESS not-accessible 394 STATUS current 395 DESCRIPTION 396 "The encapsulation method used by the tunnel." 397 ::= { tunnelConfigEntry 3 } 399 tunnelConfigID OBJECT-TYPE 400 SYNTAX Integer32 (1..2147483647) 401 MAX-ACCESS not-accessible 402 STATUS current 403 DESCRIPTION 404 "An identifier used to distinguish between multiple tunnels 405 of the same encapsulation method, with the same endpoints. 406 If the encapsulation protocol only allows one tunnel per set 407 of endpoint addresses (such as for GRE or IP-in-IP), the 408 value of this object is 1. For encapsulation methods (such 409 as L2F) which allow multiple parallel tunnels, the manager 410 is responsible for choosing any ID which does not conflict 411 with an existing row, such as choosing a random number." 412 ::= { tunnelConfigEntry 4 } 414 tunnelConfigIfIndex OBJECT-TYPE 415 SYNTAX InterfaceIndexOrZero 416 MAX-ACCESS read-only 417 STATUS current 418 DESCRIPTION 419 "If the value of tunnelConfigStatus for this row is active, 420 then this object contains the value of ifIndex corresponding 421 to the tunnel interface. A value of 0 is not legal in the 422 active state, and means that the interface index has not yet 423 been assigned." 424 ::= { tunnelConfigEntry 5 } 426 tunnelConfigStatus OBJECT-TYPE 427 SYNTAX RowStatus 428 MAX-ACCESS read-create 429 STATUS current 430 DESCRIPTION 431 "The status of this row, by which new entries may be 432 created, or old entries deleted from this table. The agent 433 need not support setting this object to createAndWait or 434 notInService since there are no other writable objects in 435 this table, and writable objects in rows of corresponding 436 tables such as the tunnelIfTable may be modified while this 437 row is active. 439 To create a row in this table for an encapsulation method 440 which does not support multiple parallel tunnels with the 441 same endpoints, the management station should simply use a 442 tunnelConfigID of 1, and set tunnelConfigStatus to 443 createAndGo. For encapsulation methods such as L2F which 444 allow multiple parallel tunnels, the management station may 445 select a pseudo-random number to use as the tunnelConfigID 446 and set tunnelConfigStatus to createAndGo. In the event 447 that this ID is already in use and an inconsistentValue is 448 returned in response to the set operation, the management 449 station should simply select a new pseudo-random number and 450 retry the operation. 452 Creating a row in this table will cause an interface index 453 to be assigned by the agent in an implementation-dependent 454 manner, and corresponding rows will be instantiated in the 455 ifTable and the tunnelIfTable. The status of this row will 456 become active as soon as the agent assigns the interface 457 index, regardless of whether the interface is operationally 458 up. 460 Deleting a row in this table will likewise delete the 461 corresponding row in the ifTable and in the tunnelIfTable." 462 ::= { tunnelConfigEntry 6 } 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 tunnelIfTOS 487 MIN-ACCESS read-only 488 DESCRIPTION 489 "Write access is not required." 491 OBJECT tunnelConfigStatus 492 MIN-ACCESS read-only 493 DESCRIPTION 494 "Write access is not required." 495 ::= { tunnelMIBCompliances 1 } 497 -- units of conformance 499 tunnelMIBBasicGroup OBJECT-GROUP 500 OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress, 501 tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS, 502 tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus } 503 STATUS current 504 DESCRIPTION 505 "A collection of objects to support basic management of IP 506 Tunnels." 507 ::= { tunnelMIBGroups 1 } 509 END 510 6. Security Considerations 512 This MIB contains readable objects whose values provide information 513 related to IP tunnel interfaces. There are also a number of objects 514 that have a MAX-ACCESS clause of read-write and/or read-create, such as 515 those which allow an administrator to dynamically configure tunnels. 517 While unauthorized access to the readable objects is relatively 518 innocuous, unauthorized access to the write-able objects could cause a 519 denial of service, or could cause unauthorized creation and/or 520 manipulation of tunnels. Hence, the support for SET operations in a 521 non-secure environment without proper protection can have a negative 522 effect on network operations. 524 SNMPv1 by itself is such an insecure environment. Even if the network 525 itself is secure (for example by using IPSec [24]), even then, there is 526 no control as to who on the secure network is allowed to access and SET 527 (change/create/delete) the objects in this MIB. 529 It is recommended that the implementers consider the security features 530 as provided by the SNMPv3 framework. Specifically, the use of the 531 User-based Security Model RFC 2574 [12] and the View-based Access 532 Control Model RFC 2575 [15] is recommended. 534 It is then a customer/user responsibility to ensure that the SNMP entity 535 giving access to this MIB, is properly configured to give access to 536 those objects only to those principals (users) that have legitimate 537 rights to access them. 539 7. Acknowledgements 541 This MIB module was updated based on feedback from the IETF's Interfaces 542 MIB (IF-MIB) and Point-to-Point Protocol Extensions (PPPEXT) Working 543 Groups. 545 8. Author's Address 547 Dave Thaler 548 Microsoft Corporation 549 One Microsoft Way 550 Redmond, WA 98052-6399 551 Phone: +1 425 703 8835 552 EMail: dthaler@microsoft.com 554 9. References 556 [1] Wijnen, B., Harrington, D., and R. Presuhn, "An Architecture for 557 Describing SNMP Management Frameworks", RFC 2571, Cabletron 558 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 559 1999. 561 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 562 Management Information for TCP/IP-based Internets", STD 16, RFC 563 1155, Performance Systems International, Hughes LAN Systems, May 564 1990. 566 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 567 1212, Performance Systems International, Hughes LAN Systems, March 568 1991. 570 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 571 RFC 1215, Performance Systems International, March 1991. 573 [5] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of 574 Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 575 1999. 577 [6] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual 578 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 580 [7] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance 581 Statements for SMIv2", STD 58, RFC 2580, April 1999. 583 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 584 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 585 Systems International, Performance Systems International, MIT 586 Laboratory for Computer Science, May 1990. 588 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 589 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 590 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 591 International Network Services, January 1996. 593 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 594 Mappings for Version 2 of the Simple Network Management Protocol 595 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 596 Dover Beach Consulting, Inc., International Network Services, 597 January 1996. 599 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 600 Processing and Dispatching for the Simple Network Management 601 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, 602 Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. 604 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 605 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 606 2574, IBM T. J. Watson Research, April 1999. 608 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 609 Operations for Version 2 of the Simple Network Management Protocol 610 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 611 Dover Beach Consulting, Inc., International Network Services, 612 January 1996. 614 [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 615 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 616 Systems, April 1999. 618 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 619 Control Model (VACM) for the Simple Network Management Protocol 620 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., 621 Cisco Systems, Inc., April 1999. 623 [16] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing 624 Encapsulation (GRE)", RFC 1701, October 1994. 626 [17] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing 627 Encapsulation over IPv4 networks", RFC 1702, October 1994. 629 [18] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. 631 [19] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 632 1996. 634 [20] Hamzeh, Kolar, Littlewood, Pall, Taarud, Valencia, and Verthein, 635 "Layer Two Tunneling Protocol (L2TP)", Work in Progress. 637 [21] Hamzeh, Pall, Verthein, Taarud, and Little, "Point-to-Point 638 Tunneling Protocol--PPTP", Work in Progress. 640 [22] K. Hamzeh. "Ascend Tunnel Management Protocol - ATMP", RFC 2107, 641 February 1997. 643 [23] McCloghrie, K., and F. Kastenholz. "The Interfaces Group MIB using 644 SMIv2", RFC 2233, November 1997. 646 [24] R. Atkinson. "Security architecture for the internet protocol", 647 RFC 2401, November 1998. 649 [25] Valencia, A., Littlewood, M., and T. Kolar. "Cisco Layer Two 650 Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 652 [26] D. Provan. "Tunneling IPX Traffic through IP Networks", RFC 1234, 653 June 1991. 655 [27] Gilligan, R., and E. Nordmark. "Transition Mechanisms for IPv6 656 Hosts and Routers", RFC 1933, April 1996. 658 [28] Woodburn, R., and D. Mills, "A Scheme for an Internet Encapsulation 659 Protocol: Version 1", RFC 1241, July 1991. 661 [29] Nichols, K., Blake, S., Baker, F., and D. Black. "Definition of 662 the Differentiated Services Field (DS Field) in the IPv4 and IPv6 663 Headers", RFC 2474, December 1998. 665 10. Full Copyright Statement 667 Copyright (C) The Internet Society (1999). All Rights Reserved. 669 This document and translations of it may be copied and furnished to 670 others, and derivative works that comment on or otherwise explain it or 671 assist in its implmentation may be prepared, copied, published and 672 distributed, in whole or in part, without restriction of any kind, 673 provided that the above copyright notice and this paragraph are included 674 on all such copies and derivative works. However, this document itself 675 may not be modified in any way, such as by removing the copyright notice 676 or references to the Internet Society or other Internet organizations, 677 except as needed for the purpose of developing Internet standards in 678 which case the procedures for copyrights defined in the Internet 679 Standards process must be followed, or as required to translate it into 680 languages other than English. 682 The limited permissions granted above are perpetual and will not be 683 revoked by the Internet Society or its successors or assigns. 685 This document and the information contained herein is provided on an "AS 686 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 687 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 688 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 689 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 690 FITNESS FOR A PARTICULAR PURPOSE." 692 Table of Contents 694 1 Abstract ........................................................ 1 695 2 Introduction .................................................... 2 696 3 The SNMP Network Management Framework ........................... 2 697 4 Overview ........................................................ 3 698 4.1 Relationship to the Interfaces MIB ............................ 3 699 4.1.1 Layering Model .............................................. 4 700 4.1.2 ifRcvAddressTable ........................................... 4 701 4.1.3 ifEntry ..................................................... 4 702 5 Definitions ..................................................... 6 703 6 Security Considerations ......................................... 15 704 7 Acknowledgements ................................................ 15 705 8 Author's Address ................................................ 15 706 9 References ...................................................... 16 707 10 Full Copyright Statement ....................................... 18