idnits 2.17.1 draft-ietf-ipv6-inet-tunnel-mib-00.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 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 942: '...It is RECOMMENDED that implementers co...' RFC 2119 keyword, line 948: '... Instead, it is RECOMMENDED to deploy...' 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 (January 2004) is 7405 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) -- Looks like a reference, but probably isn't: '20' on line 175 == Unused Reference: 'RFC3595' is defined on line 995, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2893 (Obsoleted by RFC 4213) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 INTERNET-DRAFT Microsoft 4 Expires July 2004 January 2004 6 IP Tunnel MIB 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work 23 in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 36 Draft Inet Tunnel MIB January 2004 38 This memo defines a Management Information Base (MIB) for use with 39 network management protocols in the Internet community. In 40 particular, it describes managed objects used for managing tunnels 41 of any type over IPv4 and IPv6 networks. Extension MIBs may be 42 designed for managing protocol-specific objects. Likewise, 43 extension MIBs may be designed for managing security-specific 44 objects. This MIB does not support tunnels over non-IP networks. 45 Management of such tunnels may be supported by other MIBs. 47 1. Introduction 49 Over the past several years, there have been a number of 50 "tunneling" protocols specified by the IETF (see [RFC1241] for an 51 early discussion of the model and examples). This document 52 describes a Management Information Base (MIB) used for managing 53 tunnels of any type over IPv4 networks, including GRE 54 [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal Encapsulation 55 [RFC2004], L2TP [RFC2661], PPTP [RFC2637], L2F [RFC2341], UDP 56 (e.g., [RFC1234]), ATMP [RFC2107], and IPv6-in-IPv4 [RFC2893] 57 tunnels. 59 Extension MIBs may be designed for managing protocol-specific 60 objects. Likewise, extension MIBs may be designed for managing 61 security-specific objects (e.g., IPSEC [RFC2401]), and traffic 62 conditioner [RFC2474] objects. Finally, this MIB does not support 63 tunnels over non- IPv4 networks (including IPv6 networks). 64 Management of such tunnels may be supported by other MIBs. 66 2. The Internet-Standard Management Framework 68 For a detailed overview of the documents that describe the 69 current Internet-Standard Management Framework, please refer to 70 section 7 of RFC 3410 [RFC3410]. 72 Managed objects are accessed via a virtual information store, 73 termed the Management Information Base or MIB. MIB objects are 74 generally accessed through the Simple Network Management 75 Protocol (SNMP). Objects in the MIB are defined using the 76 mechanisms defined in the Structure of Management Information 77 (SMI). This memo specifies a MIB module that is compliant to 78 the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], 79 STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 81 Draft Inet Tunnel MIB January 2004 83 3. Overview 85 This MIB module contains two current tables and one deprecated 86 table. The current tables are: 88 o the Tunnel Interface Table, containing information on the 89 tunnels known to a router; and 91 o the Tunnel Inet Config Table, which can be used for dynamic 92 creation of tunnels, and also provides a mapping from 93 endpoint addresses to the current interface index value. 95 The version of this MIB that appeared in RFC 2667 contained 96 the Tunnel Config Table, which mapped IPv4 endpoint addresses 97 to interface indexes. It is now deprecated in favor of the 98 Tunnel Inet Config Table. 100 3.1. Relationship to the Interfaces MIB 102 This section clarifies the relationship of this MIB to the 103 Interfaces MIB [RFC2863]. Several areas of correlation are 104 addressed in the following subsections. The implementor is 105 referred to the Interfaces MIB document in order to understand the 106 general intent of these areas. 108 3.1.1. Layering Model 110 Each logical interface (physical or virtual) has an ifEntry in the 111 Interfaces MIB [RFC2863]. Tunnels are handled by creating a 112 logical interface (ifEntry) for each tunnel. These are then 113 correlated, using the ifStack table of the Interfaces MIB, to 114 those interfaces on which the local IPv4 addresses of the tunnels 115 are configured. The basic model, therefore, looks something like 116 this (for example): 118 | | | | | | 119 +--+ +---+ +--+ +---+ | | 120 |IP-in-IP| | GRE | | | 121 | tunnel | | tunnel | | | 122 +--+ +---+ +--+ +---+ | | 123 | | | | | | <== attachment to underlying 124 +--+ +---------+ +----------+ +--+ interfaces, to be provided 125 | Physical interface | by ifStack table 127 Draft Inet Tunnel MIB January 2004 129 +--------------------------------+ 131 3.1.2. ifRcvAddressTable 133 The ifRcvAddressTable usage can be defined in the MIBs defining 134 the encapsulation below the network layer, and holds the local IP 135 addresses on which decapsulation will occur. For example, if IP- 136 in-IP encapsulation is being used, the ifRcvAddressTable can be 137 defined by IP- in-IP. If it is not specified, the default is that 138 one entry will exist for the tunnel interface, where 139 ifRcvAddressAddress contains the local IP address used for 140 encapsulation/decapsulation (i.e., tunnelIfLocalInetAddress in the 141 Tunnel Interface Table). 143 3.1.3. ifEntry 145 IfEntries are defined in the MIBs defining the encapsulation below 146 the network layer. For example, if IP-in-IP encapsulation [20] is 147 being used, the ifEntry is defined by IP-in-IP. 149 The ifType of a tunnel should be set to "tunnel" (131). An entry 150 in the IP Tunnel MIB will exist for every ifEntry with this 151 ifType. An implementation of the IP Tunnel MIB may allow 152 ifEntries to be created via the tunnelConfigTable. Creating a 153 tunnel will also add an entry in the ifTable and in the 154 tunnelIfTable, and deleting a tunnel will likewise delete the 155 entry in the ifTable and the tunnelIfTable. 157 The use of two different tables in this MIB was an important 158 design decision. Traditionally, ifIndex values are chosen by 159 agents, and are permitted to change across restarts. Allowing row 160 creation directly in the Tunnel Interface Table, indexed by 161 ifIndex, would complicate row creation and/or cause 162 interoperability problems (if each agent had special restrictions 163 on ifIndex). Instead, a separate table is used which is indexed 164 only by objects over which the manager has control. Namely, these 165 are the addresses of the tunnel endpoints and the encapsulation 166 protocol. Finally, an additional manager- chosen ID is used in 167 the index to support protocols such as L2F which allow multiple 168 tunnels between the same endpoints. 170 Draft Inet Tunnel MIB January 2004 172 3.1.4. ifEntry 174 IfEntries are defined in the MIBs defining the encapsulation below 175 the network layer. For example, if IP-in-IP encapsulation [20] is 176 being used, the ifEntry is defined by IP-in-IP. 178 The ifType of a tunnel should be set to "tunnel" (131). An entry 179 in the IP Tunnel MIB will exist for every ifEntry with this 180 ifType. An implementation of the IP Tunnel MIB may allow 181 ifEntries to be created via the tunnelConfigTable. Creating a 182 tunnel will also add an entry in the ifTable and in the 183 tunnelIfTable, and deleting a tunnel will likewise delete the 184 entry in the ifTable and the tunnelIfTable. 186 The use of two different tables in this MIB was an important 187 design decision. Traditionally, ifIndex values are chosen by 188 agents, and are permitted to change across restarts. Allowing row 189 creation directly in the Tunnel Interface Table, indexed by 190 ifIndex, would complicate row creation and/or cause 191 interoperability problems (if each agent had special restrictions 192 on ifIndex). Instead, a separate table is used which is indexed 193 only by objects over which the manager has control. Namely, these 194 are the addresses of the tunnel endpoints and the encapsulation 195 protocol. Finally, an additional manager- chosen ID is used in 196 the index to support protocols such as L2F which allow multiple 197 tunnels between the same endpoints. 199 4. Definitions 201 TUNNEL-MIB DEFINITIONS ::= BEGIN 203 IMPORTS 204 MODULE-IDENTITY, OBJECT-TYPE, transmission, 205 Integer32, IpAddress FROM SNMPv2-SMI 206 RowStatus, StorageType FROM SNMPv2-TC 207 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 208 InetAddressType, InetAddress FROM INET-ADDRESS-MIB 209 IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB 210 ifIndex, InterfaceIndexOrZero FROM IF-MIB 211 IANAtunnelType FROM IANA-TUNNELTYPE-MIB; 213 tunnelMIB MODULE-IDENTITY 214 LAST-UPDATED "200401191200Z" -- January 19, 2003 215 ORGANIZATION "IETF Interfaces MIB Working Group" 217 Draft Inet Tunnel MIB January 2004 219 CONTACT-INFO 220 " Dave Thaler 221 Microsoft Corporation 222 One Microsoft Way 223 Redmond, WA 98052-6399 224 EMail: dthaler@microsoft.com" 225 DESCRIPTION 226 "The MIB module for management of IP Tunnels, 227 independent of the specific encapsulation scheme in 228 use. 230 Copyright (C) The Internet Society (date). This 231 version of this MIB module is part of RFC yyyy; see 232 the RFC itself for full legal notices." 233 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 234 REVISION "199908241200Z" -- August 24, 1999 235 DESCRIPTION 236 "Initial version, published as RFC 2667." 237 REVISION "200401191200Z" -- January 19, 2003 238 DESCRIPTION 239 "Added support for IPv6. Published as RFC yyyy." 240 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 241 ::= { transmission 131 } 243 tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 } 245 tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 } 247 -- the IP Tunnel MIB-Group 248 -- 249 -- a collection of objects providing information about 250 -- IP Tunnels 252 tunnelIfTable OBJECT-TYPE 253 SYNTAX SEQUENCE OF TunnelIfEntry 254 MAX-ACCESS not-accessible 255 STATUS current 256 DESCRIPTION 257 "The (conceptual) table containing information on 258 configured tunnels." 259 ::= { tunnel 1 } 261 tunnelIfEntry OBJECT-TYPE 262 SYNTAX TunnelIfEntry 263 MAX-ACCESS not-accessible 265 Draft Inet Tunnel MIB January 2004 267 STATUS current 268 DESCRIPTION 269 "An entry (conceptual row) containing the information 270 on a particular configured tunnel." 271 INDEX { ifIndex } 272 ::= { tunnelIfTable 1 } 274 TunnelIfEntry ::= SEQUENCE { 275 tunnelIfLocalAddress IpAddress, -- deprecated 276 tunnelIfRemoteAddress IpAddress, -- deprecated 277 tunnelIfEncapsMethod IANAtunnelType, 278 tunnelIfHopLimit Integer32, 279 tunnelIfSecurity INTEGER, 280 tunnelIfTOS Integer32, 281 tunnelIfFlowLabel IPv6FlowLabelOrAny, 282 tunnelIfAddressType InetAddressType, 283 tunnelIfLocalInetAddress InetAddress, 284 tunnelIfRemoteInetAddress InetAddress 285 } 287 tunnelIfLocalAddress OBJECT-TYPE 288 SYNTAX IpAddress 289 MAX-ACCESS read-only 290 STATUS deprecated 291 DESCRIPTION 292 "The address of the local endpoint of the tunnel 293 (i.e., the source address used in the outer IP 294 header), or 0.0.0.0 if unknown or if the tunnel is 295 over IPv6. This object is deprecated in favor of 296 tunnelIfLocalInetAddress." 297 ::= { tunnelIfEntry 1 } 299 tunnelIfRemoteAddress OBJECT-TYPE 300 SYNTAX IpAddress 301 MAX-ACCESS read-only 302 STATUS deprecated 303 DESCRIPTION 304 "The address of the remote endpoint of the tunnel 305 (i.e., the destination address used in the outer IP 306 header), or 0.0.0.0 if unknown, or an IPv6 address, or 307 the tunnel is not a point-to-point link (e.g., if it 308 is a 6to4 tunnel). This object is deprecated in favor 309 of tunnelIfRemoteInetAddress." 310 ::= { tunnelIfEntry 2 } 312 Draft Inet Tunnel MIB January 2004 314 tunnelIfEncapsMethod OBJECT-TYPE 315 SYNTAX IANAtunnelType 316 MAX-ACCESS read-only 317 STATUS current 318 DESCRIPTION 319 "The encapsulation method used by the tunnel." 320 ::= { tunnelIfEntry 3 } 322 tunnelIfHopLimit OBJECT-TYPE 323 SYNTAX Integer32 (0..255) 324 MAX-ACCESS read-write 325 STATUS current 326 DESCRIPTION 327 "The IPv4 TTL or IPv6 Hop Limit to use in the outer IP 328 header. A value of 0 indicates that the value is 329 copied from the payload's header." 330 ::= { tunnelIfEntry 4 } 332 tunnelIfSecurity OBJECT-TYPE 333 SYNTAX INTEGER { 334 none(1), -- no security 335 ipsec(2), -- IPSEC security 336 other(3) 337 } 338 MAX-ACCESS read-only 339 STATUS current 340 DESCRIPTION 341 "The method used by the tunnel to secure the outer IP 342 header. The value ipsec indicates that IPsec is used 343 between the tunnel endpoints for authentication or 344 encryption or both. More specific security-related 345 information may be available in a MIB for the security 346 protocol in use." 347 ::= { tunnelIfEntry 5 } 349 tunnelIfTOS OBJECT-TYPE 350 SYNTAX Integer32 (-2..63) 351 MAX-ACCESS read-write 352 STATUS current 353 DESCRIPTION 354 "The method used to set the high 6 bits of the IPv4 355 TOS or IPv6 Traffic Class in the outer IP header. A 356 value of -1 indicates that the bits are copied from 357 the payload's header. A value of -2 indicates that a 358 traffic conditioner is invoked and more information 360 Draft Inet Tunnel MIB January 2004 362 may be available in a traffic conditioner MIB. A 363 value between 0 and 63 inclusive indicates that the 364 bit field is set to the indicated value." 365 ::= { tunnelIfEntry 6 } 367 tunnelIfFlowLabel OBJECT-TYPE 368 SYNTAX IPv6FlowLabelOrAny 369 MAX-ACCESS read-write 370 STATUS current 371 DESCRIPTION 372 "The method used to set the IPv6 Flow Label value. 373 This object need not be present in rows where 374 tunnelIfAddressType indicates the tunnel is over IPv6. 375 A value of -1 indicates that a traffic conditioner is 376 invoked and more information may be available in a 377 traffic conditioner MIB. Any other value indicates 378 that the Flow Label field is set to the indicated 379 value." 380 ::= { tunnelIfEntry 7 } 382 tunnelIfAddressType OBJECT-TYPE 383 SYNTAX InetAddressType 384 MAX-ACCESS read-write 385 STATUS current 386 DESCRIPTION 387 "The type of address in the corresponding 388 tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress 389 objects." 390 ::= { tunnelIfEntry 8 } 392 tunnelIfLocalInetAddress OBJECT-TYPE 393 SYNTAX InetAddress 394 MAX-ACCESS read-write 395 STATUS current 396 DESCRIPTION 397 "The address of the local endpoint of the tunnel 398 (i.e., the source address used in the outer IP 399 header). If the address is unknown, the value is 400 0.0.0.0 for IPv4 or :: for IPv6." 401 ::= { tunnelIfEntry 9 } 403 tunnelIfRemoteInetAddress OBJECT-TYPE 404 SYNTAX InetAddress 405 MAX-ACCESS read-write 406 STATUS current 408 Draft Inet Tunnel MIB January 2004 410 DESCRIPTION 411 "The address of the remote endpoint of the tunnel 412 (i.e., the destination address used in the outer IP 413 header). If the address is unknown or the tunnel is 414 not a point-to-point link (e.g., if it is a 6to4 415 tunnel), the value is 0.0.0.0 for tunnels over IPv4 or 416 :: for tunnels over IPv6." 417 ::= { tunnelIfEntry 10 } 419 tunnelConfigTable OBJECT-TYPE 420 SYNTAX SEQUENCE OF TunnelConfigEntry 421 MAX-ACCESS not-accessible 422 STATUS deprecated 423 DESCRIPTION 424 "The (conceptual) table containing information on 425 configured tunnels. This table can be used to map a 426 set of tunnel endpoints to the associated ifIndex 427 value. It can also be used for row creation. Note 428 that every row in the tunnelIfTable with a fixed IPv4 429 destination address should have a corresponding row in 430 the tunnelConfigTable, regardless of whether it was 431 created via SNMP. This table is deprecated in favor 432 of tunnelInetConfigTable." 433 ::= { tunnel 2 } 435 tunnelConfigEntry OBJECT-TYPE 436 SYNTAX TunnelConfigEntry 437 MAX-ACCESS not-accessible 438 STATUS deprecated 439 DESCRIPTION 440 "An entry (conceptual row) containing the information 441 on a particular configured tunnel." 442 INDEX { tunnelConfigLocalAddress, 443 tunnelConfigRemoteAddress, 444 tunnelConfigEncapsMethod, 445 tunnelConfigID } 446 ::= { tunnelConfigTable 1 } 448 TunnelConfigEntry ::= SEQUENCE { 449 tunnelConfigLocalAddress IpAddress, 450 tunnelConfigRemoteAddress IpAddress, 451 tunnelConfigEncapsMethod IANAtunnelType, 452 tunnelConfigID Integer32, 453 tunnelConfigIfIndex InterfaceIndexOrZero, 454 tunnelConfigStatus RowStatus 456 Draft Inet Tunnel MIB January 2004 458 } 460 tunnelConfigLocalAddress OBJECT-TYPE 461 SYNTAX IpAddress 462 MAX-ACCESS not-accessible 463 STATUS deprecated 464 DESCRIPTION 465 "The address of the local endpoint of the tunnel, or 466 0.0.0.0 if the device is free to choose any of its 467 addresses at tunnel establishment time." 468 ::= { tunnelConfigEntry 1 } 470 tunnelConfigRemoteAddress OBJECT-TYPE 471 SYNTAX IpAddress 472 MAX-ACCESS not-accessible 473 STATUS deprecated 474 DESCRIPTION 475 "The address of the remote endpoint of the tunnel." 476 ::= { tunnelConfigEntry 2 } 478 tunnelConfigEncapsMethod OBJECT-TYPE 479 SYNTAX IANAtunnelType 480 MAX-ACCESS not-accessible 481 STATUS deprecated 482 DESCRIPTION 483 "The encapsulation method used by the tunnel." 484 ::= { tunnelConfigEntry 3 } 486 tunnelConfigID OBJECT-TYPE 487 SYNTAX Integer32 (1..2147483647) 488 MAX-ACCESS not-accessible 489 STATUS deprecated 490 DESCRIPTION 491 "An identifier used to distinguish between multiple 492 tunnels of the same encapsulation method, with the 493 same endpoints. If the encapsulation protocol only 494 allows one tunnel per set of endpoint addresses (such 495 as for GRE or IP-in-IP), the value of this object is 496 1. For encapsulation methods (such as L2F) which 497 allow multiple parallel tunnels, the manager is 498 responsible for choosing any ID which does not 499 conflict with an existing row, such as choosing a 500 random number." 501 ::= { tunnelConfigEntry 4 } 503 Draft Inet Tunnel MIB January 2004 505 tunnelConfigIfIndex OBJECT-TYPE 506 SYNTAX InterfaceIndexOrZero 507 MAX-ACCESS read-only 508 STATUS deprecated 509 DESCRIPTION 510 "If the value of tunnelConfigStatus for this row is 511 active, then this object contains the value of ifIndex 512 corresponding to the tunnel interface. A value of 0 513 is not legal in the active state, and means that the 514 interface index has not yet been assigned." 515 ::= { tunnelConfigEntry 5 } 517 tunnelConfigStatus OBJECT-TYPE 518 SYNTAX RowStatus 519 MAX-ACCESS read-create 520 STATUS deprecated 521 DESCRIPTION 522 "The status of this row, by which new entries may be 523 created, or old entries deleted from this table. The 524 agent need not support setting this object to 525 createAndWait or notInService since there are no other 526 writable objects in this table, and writable objects 527 in rows of corresponding tables such as the 528 tunnelIfTable may be modified while this row is 529 active. 531 To create a row in this table for an encapsulation 532 method which does not support multiple parallel 533 tunnels with the same endpoints, the management 534 station should simply use a tunnelConfigID of 1, and 535 set tunnelConfigStatus to createAndGo. For 536 encapsulation methods such as L2F which allow multiple 537 parallel tunnels, the management station may select a 538 pseudo-random number to use as the tunnelConfigID and 539 set tunnelConfigStatus to createAndGo. In the event 540 that this ID is already in use and an 541 inconsistentValue is returned in response to the set 542 operation, the management station should simply select 543 a new pseudo-random number and retry the operation. 545 Creating a row in this table will cause an interface 546 index to be assigned by the agent in an 547 implementation-dependent manner, and corresponding 548 rows will be instantiated in the ifTable and the 549 tunnelIfTable. The status of this row will become 551 Draft Inet Tunnel MIB January 2004 553 active as soon as the agent assigns the interface 554 index, regardless of whether the interface is 555 operationally up. 557 Deleting a row in this table will likewise delete the 558 corresponding row in the ifTable and in the 559 tunnelIfTable." 560 ::= { tunnelConfigEntry 6 } 562 tunnelInetConfigTable OBJECT-TYPE 563 SYNTAX SEQUENCE OF TunnelInetConfigEntry 564 MAX-ACCESS not-accessible 565 STATUS current 566 DESCRIPTION 567 "The (conceptual) table containing information on 568 configured tunnels. This table can be used to map a 569 set of tunnel endpoints to the associated ifIndex 570 value. It can also be used for row creation. Note 571 that every row in the tunnelIfTable with a fixed 572 destination address should have a corresponding row in 573 the tunnelInetConfigTable, regardless of whether it 574 was created via SNMP." 575 ::= { tunnel 3 } 577 tunnelInetConfigEntry OBJECT-TYPE 578 SYNTAX TunnelInetConfigEntry 579 MAX-ACCESS not-accessible 580 STATUS current 581 DESCRIPTION 582 "An entry (conceptual row) containing the information 583 on a particular configured tunnel. Note that there is 584 a 128 subid maximum for object OIDs. In practice this 585 is not expected to be a problem since IPv4 and IPv6 586 addresses will not cause the limit to be reached. If 587 other types are supported by an agent, care must be 588 taken to ensure that the sum of the lengths do not 589 cause the limit to be exceeded." 590 INDEX { tunnelInetConfigAddressType, 591 tunnelInetConfigLocalAddress, 592 tunnelInetConfigRemoteAddress, 593 tunnelInetConfigEncapsMethod, 594 tunnelInetConfigID } 595 ::= { tunnelInetConfigTable 1 } 597 TunnelInetConfigEntry ::= SEQUENCE { 598 Draft Inet Tunnel MIB January 2004 600 tunnelInetConfigAddressType InetAddressType, 601 tunnelInetConfigLocalAddress InetAddress, 602 tunnelInetConfigRemoteAddress InetAddress, 603 tunnelInetConfigEncapsMethod IANAtunnelType, 604 tunnelInetConfigID Integer32, 605 tunnelInetConfigIfIndex InterfaceIndexOrZero, 606 tunnelInetConfigStatus RowStatus, 607 tunnelInetConfigStorageType StorageType 608 } 610 tunnelInetConfigAddressType OBJECT-TYPE 611 SYNTAX InetAddressType 612 MAX-ACCESS not-accessible 613 STATUS current 614 DESCRIPTION 615 "The address type over which the tunnel encapsulates 616 packets." 617 ::= { tunnelInetConfigEntry 1 } 619 tunnelInetConfigLocalAddress OBJECT-TYPE 620 SYNTAX InetAddress 621 MAX-ACCESS not-accessible 622 STATUS current 623 DESCRIPTION 624 "The address of the local endpoint of the tunnel, or 625 0.0.0.0 if the device is free to choose any of its 626 addresses at tunnel establishment time." 627 ::= { tunnelInetConfigEntry 2 } 629 tunnelInetConfigRemoteAddress OBJECT-TYPE 630 SYNTAX InetAddress 631 MAX-ACCESS not-accessible 632 STATUS current 633 DESCRIPTION 634 "The address of the remote endpoint of the tunnel." 635 ::= { tunnelInetConfigEntry 3 } 637 tunnelInetConfigEncapsMethod OBJECT-TYPE 638 SYNTAX IANAtunnelType 639 MAX-ACCESS not-accessible 640 STATUS current 641 DESCRIPTION 642 "The encapsulation method used by the tunnel." 643 ::= { tunnelInetConfigEntry 4 } 645 Draft Inet Tunnel MIB January 2004 647 tunnelInetConfigID OBJECT-TYPE 648 SYNTAX Integer32 (1..2147483647) 649 MAX-ACCESS not-accessible 650 STATUS current 651 DESCRIPTION 652 "An identifier used to distinguish between multiple 653 tunnels of the same encapsulation method, with the 654 same endpoints. If the encapsulation protocol only 655 allows one tunnel per set of endpoint addresses (such 656 as for GRE or IP-in-IP), the value of this object is 657 1. For encapsulation methods (such as L2F) which 658 allow multiple parallel tunnels, the manager is 659 responsible for choosing any ID which does not 660 conflict with an existing row, such as choosing a 661 random number." 662 ::= { tunnelInetConfigEntry 5 } 664 tunnelInetConfigIfIndex OBJECT-TYPE 665 SYNTAX InterfaceIndexOrZero 666 MAX-ACCESS read-only 667 STATUS current 668 DESCRIPTION 669 "If the value of tunnelInetConfigStatus for this row 670 is active, then this object contains the value of 671 ifIndex corresponding to the tunnel interface. A 672 value of 0 is not legal in the active state, and means 673 that the interface index has not yet been assigned." 674 ::= { tunnelInetConfigEntry 6 } 676 tunnelInetConfigStatus OBJECT-TYPE 677 SYNTAX RowStatus 678 MAX-ACCESS read-create 679 STATUS current 680 DESCRIPTION 681 "The status of this row, by which new entries may be 682 created, or old entries deleted from this table. The 683 agent need not support setting this object to 684 createAndWait or notInService since there are no other 685 writable objects in this table, and writable objects 686 in rows of corresponding tables such as the 687 tunnelIfTable may be modified while this row is 688 active. 690 To create a row in this table for an encapsulation 691 method which does not support multiple parallel 693 Draft Inet Tunnel MIB January 2004 695 tunnels with the same endpoints, the management 696 station should simply use a tunnelInetConfigID of 1, 697 and set tunnelInetConfigStatus to createAndGo. For 698 encapsulation methods such as L2F which allow multiple 699 parallel tunnels, the management station may select a 700 pseudo-random number to use as the tunnelInetConfigID 701 and set tunnelInetConfigStatus to createAndGo. In the 702 event that this ID is already in use and an 703 inconsistentValue is returned in response to the set 704 operation, the management station should simply select 705 a new pseudo-random number and retry the operation. 707 Creating a row in this table will cause an interface 708 index to be assigned by the agent in an 709 implementation-dependent manner, and corresponding 710 rows will be instantiated in the ifTable and the 711 tunnelIfTable. The status of this row will become 712 active as soon as the agent assigns the interface 713 index, regardless of whether the interface is 714 operationally up. 716 Deleting a row in this table will likewise delete the 717 corresponding row in the ifTable and in the 718 tunnelIfTable." 719 ::= { tunnelInetConfigEntry 7 } 721 tunnelInetConfigStorageType OBJECT-TYPE 722 SYNTAX StorageType 723 MAX-ACCESS read-create 724 STATUS current 725 DESCRIPTION 726 "The storage type of this row. If the row is 727 permanent(4), no objects in the row need be writable." 728 ::= { tunnelInetConfigEntry 8 } 730 -- conformance information 732 tunnelMIBConformance 733 OBJECT IDENTIFIER ::= { tunnelMIB 2 } 734 tunnelMIBCompliances 735 OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 } 736 tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 } 738 -- compliance statements 739 Draft Inet Tunnel MIB January 2004 741 tunnelMIBCompliance MODULE-COMPLIANCE 742 STATUS deprecated 743 DESCRIPTION 744 "The (deprecated) IPv4-only compliance statement for 745 the IP Tunnel MIB." 746 MODULE -- this module 747 MANDATORY-GROUPS { tunnelMIBGroup } 749 OBJECT tunnelIfHopLimit 750 MIN-ACCESS read-only 751 DESCRIPTION 752 "Write access is not required." 754 OBJECT tunnelIfTOS 755 MIN-ACCESS read-only 756 DESCRIPTION 757 "Write access is not required." 759 OBJECT tunnelConfigStatus 760 MIN-ACCESS read-only 761 DESCRIPTION 762 "Write access is not required." 763 ::= { tunnelMIBCompliances 1 } 765 tunnelMIBInetReadWriteCompliance MODULE-COMPLIANCE 766 STATUS deprecated 767 DESCRIPTION 768 "The full compliance statement for the IP Tunnel MIB." 769 MODULE -- this module 770 MANDATORY-GROUPS { tunnelMIBInetGroup } 772 OBJECT tunnelIfAddressType 773 SYNTAX InetAddressType { ipv4(1), ipv6(2), 774 ipv4z(3), ipv6z(4) } 775 DESCRIPTION 776 "An implementation is only required to support IPv4 777 and/or IPv6 addresses. An implementation only needs to 778 support the addresses it actually supports on the 779 device." 781 OBJECT tunnelInetConfigStatus 782 SYNTAX RowStatus { active(1) } 783 WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } 784 DESCRIPTION 785 "Support for createAndWait and notInService is not 787 Draft Inet Tunnel MIB January 2004 789 required." 790 ::= { tunnelMIBCompliances 2 } 792 tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE 793 STATUS deprecated 794 DESCRIPTION 795 "The read-only compliance statement for the IP Tunnel 796 MIB." 797 MODULE -- this module 798 MANDATORY-GROUPS { tunnelMIBInetGroup } 800 OBJECT tunnelIfHopLimit 801 MIN-ACCESS read-only 802 DESCRIPTION 803 "Write access is not required." 805 OBJECT tunnelIfTOS 806 MIN-ACCESS read-only 807 DESCRIPTION 808 "Write access is not required." 810 OBJECT tunnelIfFlowLabel 811 MIN-ACCESS read-only 812 DESCRIPTION 813 "Write access is not required." 815 OBJECT tunnelIfAddressType 816 SYNTAX InetAddressType { ipv4(1), ipv6(2), 817 ipv4z(3), ipv6z(4) } 818 MIN-ACCESS read-only 819 DESCRIPTION 820 "Write access is not required. 822 An implementation is only required to support IPv4 823 and/or IPv6 addresses. An implementation only needs to 824 support the addresses it actually supports on the 825 device." 827 OBJECT tunnelIfLocalInetAddress 828 MIN-ACCESS read-only 829 DESCRIPTION 830 "Write access is not required." 832 OBJECT tunnelIfRemoteInetAddress 833 MIN-ACCESS read-only 835 Draft Inet Tunnel MIB January 2004 837 DESCRIPTION 838 "Write access is not required." 840 OBJECT tunnelInetConfigStatus 841 SYNTAX RowStatus { active(1) } 842 MIN-ACCESS read-only 843 DESCRIPTION 844 "Write access is not required, and active is the only 845 status that needs to be supported." 847 OBJECT tunnelInetConfigStorageType 848 MIN-ACCESS read-only 849 DESCRIPTION 850 "Write access is not required." 851 ::= { tunnelMIBCompliances 3 } 853 -- units of conformance 855 tunnelMIBGroup OBJECT-GROUP 856 OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress, 857 tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS, 858 tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus } 859 STATUS deprecated 860 DESCRIPTION 861 "A collection of objects to support basic management 862 of IPv4 Tunnels." 863 ::= { tunnelMIBGroups 1 } 865 tunnelMIBInetGroup OBJECT-GROUP 866 OBJECTS { tunnelIfAddressType, tunnelIfLocalInetAddress, 867 tunnelIfRemoteInetAddress, tunnelIfEncapsMethod, 868 tunnelIfHopLimit, tunnelIfTOS, tunnelIfFlowLabel, 869 tunnelIfSecurity, tunnelInetConfigIfIndex, 870 tunnelInetConfigStatus, tunnelInetConfigStorageType } 871 STATUS current 872 DESCRIPTION 873 "A collection of objects to support basic management 874 of IPv4 and IPv6 Tunnels." 875 ::= { tunnelMIBGroups 2 } 877 END 878 Draft Inet Tunnel MIB January 2004 880 5. IANA Considerations 882 This document introduces a new IANA-maintained textual convention 883 (TC) which is to be added to the IANAifType-MIB. The initial 884 version of this IANAtunnelType TC can be found in Appendix A. The 885 current version of the textual convention can be accessed at 886 http://www.iana.org/assignments/ianaiftype-mib 888 The policy for assigning new IANAtunnelType values is First Come 889 First Served, as defined in [RFC2434], just as it is for new 890 IANAifTypes values. The assignment policy for IANAtunnelType 891 values should always be identical to the policy for assigning 892 IANAifType values. 894 New types of tunnels over IPv4 or IPv6 should not be assigned 895 IANAifType values. Instead, they should be assigned 896 IANAtunnelType values and hence reuse the interface type 897 tunnel(131). (Note this restriction does not apply to "tunnels" 898 which are not over IPv4 or IPv6.) 900 Previously tunnel types which were not point-to-point tunnels were 901 problematic in that they could not be properly expressed in the 902 tunnel MIB, and hence were assigned IANAifType values. This 903 document now corrects this problem, and as a result, IANA should 904 deprecate the sixToFour(215) IANAifType value in favor of the 905 sixToFour(11) IANAtunnelType value. 907 6. Security Considerations 909 There are a number of management objects defined in this MIB 910 module with a MAX-ACCESS clause of read-write and/or read-create. 911 Such objects may be considered sensitive or vulnerable in some 912 network environments. The support for SET operations in a non- 913 secure environment without proper protection can have a negative 914 effect on network operations. 916 Unauthorized write access to any of the writable objects could 917 cause unauthorized creation and/or manipulation of tunnels, 918 resulting in a denial of service, or redirection of packets to an 919 arbitrary destination. 921 Some of the readable objects in this MIB module (i.e., objects 922 with a MAX-ACCESS other than not-accessible) may be considered 923 sensitive or vulnerable in some network environments. It is thus 924 Draft Inet Tunnel MIB January 2004 926 important to control even GET and/or NOTIFY access to these 927 objects and possibly to even encrypt the values of these objects 928 when sending them over the network via SNMP. 930 Unauthorized read access to tunnelIfLocalInetAddress, 931 tunnelIfRemoteInetAddress, tunnelIfLocalAddress, 932 tunnelIfRemoteAddress, or any object in the tunnelConfigTable or 933 tunnelInetConfigTable would reveal information about the tunnel 934 topology. 936 SNMP versions prior to SNMPv3 did not include adequate security. 937 Even if the network itself is secure (for example by using IPSec), 938 even then, there is no control as to who on the secure network is 939 allowed to access and GET/SET (read/change/create/delete) the 940 objects in this MIB module. 942 It is RECOMMENDED that implementers consider the security features 943 as provided by the SNMPv3 framework (see [RFC3410], section 8), 944 including full support for the SNMPv3 cryptographic mechanisms 945 (for authentication and privacy). 947 Further, deployment of SNMP versions prior to SNMPv3 is NOT 948 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 949 enable cryptographic security. It is then a customer/operator 950 responsibility to ensure that the SNMP entity giving access to an 951 instance of this MIB module is properly configured to give access 952 to the objects only to those principals (users) that have 953 legitimate rights to indeed GET or SET (change/create/delete) 954 them. 956 7. Acknowledgements 958 This MIB module was updated based on feedback from the IETF's 959 Interfaces MIB (IF-MIB) and Point-to-Point Protocol Extensions 960 (PPPEXT) Working Groups. 962 8. Authors' Addresses 964 Dave Thaler 965 Microsoft Corporation 966 One Microsoft Way 967 Redmond, WA 98052-6399 968 Draft Inet Tunnel MIB January 2004 970 Phone: +1 425 703 8835 971 EMail: dthaler@microsoft.com 973 9. Normative References 975 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 976 an IANA Considerations Section in RFCs", RFC 2434, 977 October 1998. 979 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 980 J., Rose, M. and S. Waldbusser, "Structure of 981 Management Information Version 2 (SMIv2)", STD 58, RFC 982 2578, April 1999. 984 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 985 J., Rose, M. and S. Waldbusser, "Textual Conventions 986 for SMIv2", STD 58, RFC 2579, April 1999. 988 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 989 J., Rose, M. and S. Waldbusser, "Conformance 990 Statements for SMIv2", STD 58, RFC 2580, April 1999. 992 [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces 993 Group MIB", RFC 2863, June 2000. 995 [RFC3595] B. Wijnen, "Textual Conventions for IPv6 Flow Label", 996 RFC 3595, September 2003. 998 10. Informative References 1000 [RFC1234] D. Provan, "Tunneling IPX Traffic through IP 1001 Networks", RFC 1234, June 1991. 1003 [RFC1241] Woodburn, R. and D. Mills, "A Scheme for an Internet 1004 Encapsulation Protocol: Version 1", RFC 1241, July 1005 1991. 1007 [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, 1008 "Generic Routing Encapsulation (GRE)", RFC 1701, 1009 October 1994. 1011 [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, 1012 "Generic Routing Encapsulation over IPv4 networks", 1014 Draft Inet Tunnel MIB January 2004 1016 RFC 1702, October 1994. 1018 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1019 October 1996. 1021 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 1022 2004, October 1996. 1024 [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - 1025 ATMP", RFC 2107, February 1997. 1027 [RFC2341] Valencia, A., Littlewood, M. and T. Kolar. "Cisco 1028 Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1029 1998. 1031 [RFC2401] R. Atkinson, "Security architecture for the internet 1032 protocol", RFC 2401, November 1998. 1034 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black. 1035 "Definition of the Differentiated Services Field (DS 1036 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1037 December 1998. 1039 [RFC2637] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little, 1040 W. and G. Zorn, "Point-to-Point Tunneling Protocol", 1041 RFC 2637, July 1999. 1043 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., 1044 Zorn, G. and B. Palter, "Layer Two Tunneling Protocol 1045 "L2TP"", RFC 2661, August 1999. 1047 [RFC2893] Gilligan, R. and E. Nordmark. "Transition Mechanisms 1048 for IPv6 Hosts and Routers", RFC 2893, August 2000. 1050 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1051 "Introduction and Applicability Statements for 1052 Internet-Standard Management Framework", RFC 3410, 1053 December 2002. 1055 11. Appendix A: IANA Tunnel Type TC 1057 This appendix defines the initial content of the IANAtunnelType 1058 textual convention which should appear in the IANAifType-MIB. 1060 Draft Inet Tunnel MIB January 2004 1062 IANAtunnelType ::= TEXTUAL-CONVENTION 1063 STATUS current 1064 DESCRIPTION 1065 "The encapsulation method used by a tunnel. The value 1066 direct indicates that a packet is encapsulated 1067 directly within a normal IP header, with no 1068 intermediate header, and unicast to the remote tunnel 1069 endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC 1070 1933 IPv6-in-IPv4 tunnel). The value minimal indicates 1071 that a Minimal Forwarding Header (RFC 2004) is 1072 inserted between the outer header and the payload 1073 packet. The value UDP indicates that the payload 1074 packet is encapsulated within a normal UDP packet 1075 (e.g., RFC 1234). 1077 The values sixToFour, sixOverFour, and isatap 1078 indicates that an IPv6 packet is encapsulated directly 1079 within an IPv4 header, with no intermediate header, 1080 and unicast to the destination determined by the 6to4, 1081 6over4, or ISATAP protocol. 1083 The remaining protocol-specific values indicate that a 1084 header of the protocol of that name is inserted 1085 between the outer header and the payload header." 1086 SYNTAX INTEGER { 1087 other(1), -- none of the following 1088 direct(2), -- no intermediate header 1089 gre(3), -- GRE encapsulation 1090 minimal(4), -- Minimal encapsulation 1091 l2tp(5), -- L2TP encapsulation 1092 pptp(6), -- PPTP encapsulation 1093 l2f(7), -- L2F encapsulation 1094 udp(8), -- UDP encapsulation 1095 atmp(9), -- ATMP encapsulation 1096 msdp(10), -- MSDP encapsulation 1097 sixToFour(11), -- 6to4 encapsulation 1098 sixOverFour(12), -- 6over4 encapsulation 1099 isatap(13), -- ISATAP encapsulation 1100 teredo(14) -- Teredo encapsulation 1101 } 1103 Draft Inet Tunnel MIB January 2004 1105 12. Full Copyright Statement 1107 Copyright (C) The Internet Society (2004). All Rights Reserved. 1109 This document and translations of it may be copied and furnished 1110 to others, and derivative works that comment on or otherwise 1111 explain it or assist in its implmentation may be prepared, copied, 1112 published and distributed, in whole or in part, without 1113 restriction of any kind, provided that the above copyright notice 1114 and this paragraph are included on all such copies and derivative 1115 works. However, this document itself may not be modified in any 1116 way, such as by removing the copyright notice or references to the 1117 Internet Society or other Internet organizations, except as needed 1118 for the purpose of developing Internet standards in which case the 1119 procedures for copyrights defined in the Internet Standards 1120 process must be followed, or as required to translate it into 1121 languages other than English. 1123 The limited permissions granted above are perpetual and will not 1124 be revoked by the Internet Society or its successors or assigns. 1126 This document and the information contained herein is provided on 1127 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1128 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1129 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1130 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1131 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1133 13. Intellectual Property 1135 The IETF takes no position regarding the validity or scope of any 1136 intellectual property or other rights that might be claimed to 1137 pertain to the implementation or use of the technology described 1138 in this document or the extent to which any license under such 1139 rights might or might not be available; neither does it represent 1140 that it has made any effort to identify any such rights. 1141 Information on the IETF's procedures with respect to rights in 1142 standards-track and standards-related documentation can be found 1143 in BCP-11. Copies of claims of rights made available for 1144 publication and any assurances of licenses to be made available, 1145 or the result of an attempt made to obtain a general license or 1146 permission for the use of such proprietary rights by implementors 1147 or users of this specification can be obtained from the IETF 1148 Secretariat. 1150 Draft Inet Tunnel MIB January 2004 1152 The IETF invites any interested party to bring to its attention 1153 any copyrights, patents or patent applications, or other 1154 proprietary rights which may cover technology that may be required 1155 to practice this standard. Please address the information to the 1156 IETF Executive Director."