idnits 2.17.1 draft-ietf-ipv6-inet-tunnel-mib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 34), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 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 999: '...It is RECOMMENDED that implementers co...' RFC 2119 keyword, line 1005: '... Instead, it is RECOMMENDED to deploy...' -- The abstract seems to indicate that this document obsoletes RFC2667, but the header doesn't have an 'Obsoletes:' line to match this. 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 (August 2004) is 7193 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 150 == Missing Reference: 'RFC3579' is mentioned on line 184, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IFTYPE' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3291 (Obsoleted by RFC 4001) -- 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: 15 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Thaler 2 INTERNET-DRAFT Microsoft 3 Expires February 2005 August 2004 5 IP Tunnel MIB 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been 12 disclosed, or will be disclosed, and any of which I become aware 13 will be disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than a "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Draft Inet Tunnel MIB August 2004 38 Abstract 40 This memo defines a Management Information Base (MIB) module for 41 use with network management protocols in the Internet community. 42 In particular, it describes managed objects used for managing 43 tunnels of any type over IPv4 and IPv6 networks. Extension MIB 44 modules may be designed for managing protocol-specific objects. 45 Likewise, extension MIB modules may be designed for managing 46 security-specific objects. This MIB module does not support 47 tunnels over non-IP networks. Management of such tunnels may be 48 supported by other MIB modules. 50 This memo obsoletes RFC 2667. 52 1. Introduction 54 Over the past several years, there have been a number of 55 "tunneling" protocols specified by the IETF (see [RFC1241] for an 56 early discussion of the model and examples). This document 57 describes a Management Information Base (MIB) module used for 58 managing tunnels of any type over IPv4 and IPv6 networks, 59 including GRE [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal 60 Encapsulation [RFC2004], L2TP [RFC2661], PPTP [RFC2637], L2F 61 [RFC2341], UDP (e.g., [RFC1234]), ATMP [RFC2107], and IPv6-in-IPv4 62 [RFC2893] tunnels, among others. 64 Extension MIB modules may be designed for managing protocol- 65 specific objects. Likewise, extension MIB modules may be designed 66 for managing security-specific objects (e.g., IPSEC [RFC2401]), 67 and traffic conditioner [RFC2474] objects. 69 2. The Internet-Standard Management Framework 71 For a detailed overview of the documents that describe the current 72 Internet-Standard Management Framework, please refer to section 7 73 of RFC 3410 [RFC3410]. 75 Managed objects are accessed via a virtual information store, 76 termed the Management Information Base or MIB. MIB objects are 77 generally accessed through the Simple Network Management Protocol 78 (SNMP). Objects in the MIB are defined using the mechanisms 79 defined in the Structure of Management Information (SMI). This 80 memo specifies a MIB module that is compliant to the SMIv2, which 81 Draft Inet Tunnel MIB August 2004 83 is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 84 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 86 3. Overview 88 This MIB module contains two current tables and one deprecated 89 table. The current tables are: 91 o the Tunnel Interface Table, containing information on the 92 tunnels known to a router; and 94 o the Tunnel Inet Config Table, which can be used for dynamic 95 creation of tunnels, and also provides a mapping from 96 endpoint addresses to the current interface index value. 98 The version of this MIB module that appeared in RFC 2667 contained 99 the Tunnel Config Table, which mapped IPv4 endpoint addresses to 100 interface indexes. It is now deprecated in favor of the Tunnel 101 Inet Config Table. 103 3.1. Relationship to the Interfaces MIB 105 This section clarifies the relationship of this MIB module to the 106 Interfaces MIB [RFC2863]. Several areas of correlation are 107 addressed in the following subsections. The implementor is 108 referred to the Interfaces MIB document in order to understand the 109 general intent of these areas. 111 3.1.1. Layering Model 113 Each logical interface (physical or virtual) has an ifEntry in the 114 Interfaces MIB [RFC2863]. Tunnels are handled by creating a 115 logical interface (ifEntry) for each tunnel. These are then 116 correlated, using the ifStack table of the Interfaces MIB, to 117 those interfaces on which the local IPv4 or IPv6 addresses of the 118 tunnels are configured. The basic model, therefore, looks 119 something like this (for example): 121 | | | | | | 122 +--+ +---+ +--+ +---+ | | 123 |IP-in-IP| | GRE | | | 124 | tunnel | | tunnel | | | 126 Draft Inet Tunnel MIB August 2004 128 +--+ +---+ +--+ +---+ | | 129 | | | | | | <== attachment to underlying 130 +--+ +---------+ +----------+ +--+ interfaces, to be provided 131 | Physical interface | by ifStack table 132 +--------------------------------+ 134 3.1.2. ifRcvAddressTable 136 The ifRcvAddressTable usage can be defined in the MIB modules 137 defining the encapsulation below the network layer, and holds the 138 local IP addresses on which decapsulation will occur. For 139 example, if IP-in-IP encapsulation is being used, the 140 ifRcvAddressTable can be defined by IP- in-IP. If it is not 141 specified, the default is that one entry will exist for the tunnel 142 interface, where ifRcvAddressAddress contains the local IP address 143 used for encapsulation/decapsulation (i.e., 144 tunnelIfLocalInetAddress in the Tunnel Interface Table). 146 3.1.3. ifEntry 148 IfEntries are defined in the MIB modules defining the 149 encapsulation below the network layer. For example, if IP-in-IP 150 encapsulation [20] is being used, the ifEntry is defined by IP-in- 151 IP. 153 The ifType of a tunnel should be set to "tunnel" (131). An entry 154 in the IP Tunnel MIB module will exist for every ifEntry with this 155 ifType. An implementation of the IP Tunnel MIB module may allow 156 ifEntries to be created via the tunnelConfigTable. Creating a 157 tunnel will also add an entry in the ifTable and in the 158 tunnelIfTable, and deleting a tunnel will likewise delete the 159 entry in the ifTable and the tunnelIfTable. 161 The use of two different tables in this MIB module was an 162 important design decision. Traditionally, ifIndex values are 163 chosen by agents, and are permitted to change across restarts. 164 Allowing row creation directly in the Tunnel Interface Table, 165 indexed by ifIndex, would complicate row creation and/or cause 166 interoperability problems (if each agent had special restrictions 167 on ifIndex). Instead, a separate table is used which is indexed 168 only by objects over which the manager has control. Namely, these 169 are the addresses of the tunnel endpoints and the encapsulation 170 protocol. Finally, an additional manager- chosen ID is used in 171 Draft Inet Tunnel MIB August 2004 173 the index to support protocols such as L2F which allow multiple 174 tunnels between the same endpoints. 176 4. Definitions 178 TUNNEL-MIB DEFINITIONS ::= BEGIN 180 IMPORTS 181 MODULE-IDENTITY, OBJECT-TYPE, transmission, 182 Integer32, IpAddress FROM SNMPv2-SMI -- [RFC2578] 184 RowStatus, StorageType FROM SNMPv2-TC -- [RFC3579] 186 MODULE-COMPLIANCE, 187 OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] 189 InetAddressType, 190 InetAddress FROM INET-ADDRESS-MIB -- [RFC3291] 192 IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB -- [RFC3595] 194 ifIndex, 195 InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] 197 IANAtunnelType FROM IANAifType-MIB; -- [IFTYPE] 199 tunnelMIB MODULE-IDENTITY 200 LAST-UPDATED "200408031200Z" -- August 3, 2004 201 ORGANIZATION "IETF IP Version 6 (IPv6) Working Group" 202 CONTACT-INFO 203 " Dave Thaler 204 Microsoft Corporation 205 One Microsoft Way 206 Redmond, WA 98052-6399 207 EMail: dthaler@microsoft.com" 208 DESCRIPTION 209 "The MIB module for management of IP Tunnels, 210 independent of the specific encapsulation scheme in 211 use. 213 Copyright (C) The Internet Society (date). This 214 version of this MIB module is part of RFC yyyy; see 215 the RFC itself for full legal notices." 216 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 217 Draft Inet Tunnel MIB August 2004 219 REVISION "200408031200Z" -- August 3, 2004 220 DESCRIPTION 221 "IPv4-specific objects were deprecated, including 222 tunnelIfLocalAddress, tunnelIfRemoteAddress, the 223 tunnelConfigTable, and the tunnelMIBBasicGroup. 225 Added IP version-agnostic objects that should be used 226 instead, including tunnelIfAddressType, 227 tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, 228 the tunnelInetConfigTable, and the 229 tunnelIMIBInetGroup. 231 The new tunnelIfLocalInetAddress and 232 tunnelIfRemoteInetAddress objects are read-write, 233 rather than read-only. 235 Updated DESCRIPTION clauses of existing version- 236 agnostic objects (e.g., tunnelIfTOS) that contained 237 IPv4-specific text to cover IPv6 as well. 239 Added tunnelIfFlowLabel for tunnels over IPv6. 241 The encapsulation method was previously an INTEGER 242 type, and is now an IANA-maintained textual 243 convention. 245 Published as RFC yyyy." 246 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 247 REVISION "199908241200Z" -- August 24, 1999 248 DESCRIPTION 249 "Initial version, published as RFC 2667." 250 ::= { transmission 131 } 252 tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 } 254 tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 } 256 -- the IP Tunnel MIB-Group 257 -- 258 -- a collection of objects providing information about 259 -- IP Tunnels 261 tunnelIfTable OBJECT-TYPE 262 SYNTAX SEQUENCE OF TunnelIfEntry 263 MAX-ACCESS not-accessible 265 Draft Inet Tunnel MIB August 2004 267 STATUS current 268 DESCRIPTION 269 "The (conceptual) table containing information on 270 configured tunnels." 271 ::= { tunnel 1 } 273 tunnelIfEntry OBJECT-TYPE 274 SYNTAX TunnelIfEntry 275 MAX-ACCESS not-accessible 276 STATUS current 277 DESCRIPTION 278 "An entry (conceptual row) containing the information 279 on a particular configured tunnel." 280 INDEX { ifIndex } 281 ::= { tunnelIfTable 1 } 283 TunnelIfEntry ::= SEQUENCE { 284 tunnelIfLocalAddress IpAddress, -- deprecated 285 tunnelIfRemoteAddress IpAddress, -- deprecated 286 tunnelIfEncapsMethod IANAtunnelType, 287 tunnelIfHopLimit Integer32, 288 tunnelIfSecurity INTEGER, 289 tunnelIfTOS Integer32, 290 tunnelIfFlowLabel IPv6FlowLabelOrAny, 291 tunnelIfAddressType InetAddressType, 292 tunnelIfLocalInetAddress InetAddress, 293 tunnelIfRemoteInetAddress InetAddress 294 } 296 tunnelIfLocalAddress OBJECT-TYPE 297 SYNTAX IpAddress 298 MAX-ACCESS read-only 299 STATUS deprecated 300 DESCRIPTION 301 "The address of the local endpoint of the tunnel 302 (i.e., the source address used in the outer IP 303 header), or 0.0.0.0 if unknown or if the tunnel is 304 over IPv6. 306 Since this object does not support IPv6, it is 307 deprecated in favor of tunnelIfLocalInetAddress." 308 ::= { tunnelIfEntry 1 } 310 tunnelIfRemoteAddress OBJECT-TYPE 311 SYNTAX IpAddress 313 Draft Inet Tunnel MIB August 2004 315 MAX-ACCESS read-only 316 STATUS deprecated 317 DESCRIPTION 318 "The address of the remote endpoint of the tunnel 319 (i.e., the destination address used in the outer IP 320 header), or 0.0.0.0 if unknown, or an IPv6 address, or 321 the tunnel is not a point-to-point link (e.g., if it 322 is a 6to4 tunnel). 324 Since this object does not support IPv6, it is 325 deprecated in favor of tunnelIfRemoteInetAddress." 326 ::= { tunnelIfEntry 2 } 328 tunnelIfEncapsMethod OBJECT-TYPE 329 SYNTAX IANAtunnelType 330 MAX-ACCESS read-only 331 STATUS current 332 DESCRIPTION 333 "The encapsulation method used by the tunnel." 334 ::= { tunnelIfEntry 3 } 336 tunnelIfHopLimit OBJECT-TYPE 337 SYNTAX Integer32 (0 | 1..255) 338 MAX-ACCESS read-write 339 STATUS current 340 DESCRIPTION 341 "The IPv4 TTL or IPv6 Hop Limit to use in the outer IP 342 header. A value of 0 indicates that the value is 343 copied from the payload's header." 344 ::= { tunnelIfEntry 4 } 346 tunnelIfSecurity OBJECT-TYPE 347 SYNTAX INTEGER { 348 none(1), -- no security 349 ipsec(2), -- IPSEC security 350 other(3) 351 } 352 MAX-ACCESS read-only 353 STATUS current 354 DESCRIPTION 355 "The method used by the tunnel to secure the outer IP 356 header. The value ipsec indicates that IPsec is used 357 between the tunnel endpoints for authentication or 358 encryption or both. More specific security-related 359 information may be available in a MIB module for the 361 Draft Inet Tunnel MIB August 2004 363 security protocol in use." 364 ::= { tunnelIfEntry 5 } 366 tunnelIfTOS OBJECT-TYPE 367 SYNTAX Integer32 (-2..63) 368 MAX-ACCESS read-write 369 STATUS current 370 DESCRIPTION 371 "The method used to set the high 6 bits (the 372 differentiated services codepoint) of the IPv4 TOS or 373 IPv6 Traffic Class in the outer IP header. A value of 374 -1 indicates that the bits are copied from the 375 payload's header. A value of -2 indicates that a 376 traffic conditioner is invoked and more information 377 may be available in a traffic conditioner MIB module. 378 A value between 0 and 63 inclusive indicates that the 379 bit field is set to the indicated value." 380 ::= { tunnelIfEntry 6 } 382 tunnelIfFlowLabel OBJECT-TYPE 383 SYNTAX IPv6FlowLabelOrAny 384 MAX-ACCESS read-write 385 STATUS current 386 DESCRIPTION 387 "The method used to set the IPv6 Flow Label value. 388 This object need not be present in rows where 389 tunnelIfAddressType indicates the tunnel is not over 390 IPv6. A value of -1 indicates that a traffic 391 conditioner is invoked and more information may be 392 available in a traffic conditioner MIB. Any other 393 value indicates that the Flow Label field is set to 394 the indicated value." 395 ::= { tunnelIfEntry 7 } 397 tunnelIfAddressType OBJECT-TYPE 398 SYNTAX InetAddressType 399 MAX-ACCESS read-write 400 STATUS current 401 DESCRIPTION 402 "The type of address in the corresponding 403 tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress 404 objects." 405 ::= { tunnelIfEntry 8 } 407 tunnelIfLocalInetAddress OBJECT-TYPE 408 Draft Inet Tunnel MIB August 2004 410 SYNTAX InetAddress 411 MAX-ACCESS read-write 412 STATUS current 413 DESCRIPTION 414 "The address of the local endpoint of the tunnel 415 (i.e., the source address used in the outer IP 416 header). If the address is unknown, the value is 417 0.0.0.0 for IPv4 or :: for IPv6. The type of this 418 object is given by tunnelIfAddressType." 419 ::= { tunnelIfEntry 9 } 421 tunnelIfRemoteInetAddress OBJECT-TYPE 422 SYNTAX InetAddress 423 MAX-ACCESS read-write 424 STATUS current 425 DESCRIPTION 426 "The address of the remote endpoint of the tunnel 427 (i.e., the destination address used in the outer IP 428 header). If the address is unknown or the tunnel is 429 not a point-to-point link (e.g., if it is a 6to4 430 tunnel), the value is 0.0.0.0 for tunnels over IPv4 or 431 :: for tunnels over IPv6. The type of this object is 432 given by tunnelIfAddressType." 433 ::= { tunnelIfEntry 10 } 435 tunnelConfigTable OBJECT-TYPE 436 SYNTAX SEQUENCE OF TunnelConfigEntry 437 MAX-ACCESS not-accessible 438 STATUS deprecated 439 DESCRIPTION 440 "The (conceptual) table containing information on 441 configured tunnels. This table can be used to map a 442 set of tunnel endpoints to the associated ifIndex 443 value. It can also be used for row creation. Note 444 that every row in the tunnelIfTable with a fixed IPv4 445 destination address should have a corresponding row in 446 the tunnelConfigTable, regardless of whether it was 447 created via SNMP. 449 Since this table does not support IPv6, it is 450 deprecated in favor of tunnelInetConfigTable." 451 ::= { tunnel 2 } 453 tunnelConfigEntry OBJECT-TYPE 454 SYNTAX TunnelConfigEntry 456 Draft Inet Tunnel MIB August 2004 458 MAX-ACCESS not-accessible 459 STATUS deprecated 460 DESCRIPTION 461 "An entry (conceptual row) containing the information 462 on a particular configured tunnel. 464 Since this entry does not support IPv6, it is 465 deprecated in favor of tunnelInetConfigEntry." 466 INDEX { tunnelConfigLocalAddress, 467 tunnelConfigRemoteAddress, 468 tunnelConfigEncapsMethod, 469 tunnelConfigID } 470 ::= { tunnelConfigTable 1 } 472 TunnelConfigEntry ::= SEQUENCE { 473 tunnelConfigLocalAddress IpAddress, 474 tunnelConfigRemoteAddress IpAddress, 475 tunnelConfigEncapsMethod IANAtunnelType, 476 tunnelConfigID Integer32, 477 tunnelConfigIfIndex InterfaceIndexOrZero, 478 tunnelConfigStatus RowStatus 479 } 481 tunnelConfigLocalAddress OBJECT-TYPE 482 SYNTAX IpAddress 483 MAX-ACCESS not-accessible 484 STATUS deprecated 485 DESCRIPTION 486 "The address of the local endpoint of the tunnel, or 487 0.0.0.0 if the device is free to choose any of its 488 addresses at tunnel establishment time. 490 Since this object does not support IPv6, it is 491 deprecated in favor of tunnelInetConfigLocalAddress." 492 ::= { tunnelConfigEntry 1 } 494 tunnelConfigRemoteAddress OBJECT-TYPE 495 SYNTAX IpAddress 496 MAX-ACCESS not-accessible 497 STATUS deprecated 498 DESCRIPTION 499 "The address of the remote endpoint of the tunnel. 501 Since this object does not support IPv6, it is 502 deprecated in favor of tunnelInetConfigRemoteAddress." 504 Draft Inet Tunnel MIB August 2004 506 ::= { tunnelConfigEntry 2 } 508 tunnelConfigEncapsMethod OBJECT-TYPE 509 SYNTAX IANAtunnelType 510 MAX-ACCESS not-accessible 511 STATUS deprecated 512 DESCRIPTION 513 "The encapsulation method used by the tunnel. 515 Since this object does not support IPv6, it is 516 deprecated in favor of tunnelInetConfigEncapsMethod." 517 ::= { tunnelConfigEntry 3 } 519 tunnelConfigID OBJECT-TYPE 520 SYNTAX Integer32 (1..2147483647) 521 MAX-ACCESS not-accessible 522 STATUS deprecated 523 DESCRIPTION 524 "An identifier used to distinguish between multiple 525 tunnels of the same encapsulation method, with the 526 same endpoints. If the encapsulation protocol only 527 allows one tunnel per set of endpoint addresses (such 528 as for GRE or IP-in-IP), the value of this object is 529 1. For encapsulation methods (such as L2F) which 530 allow multiple parallel tunnels, the manager is 531 responsible for choosing any ID which does not 532 conflict with an existing row, such as choosing a 533 random number. 535 Since this object does not support IPv6, it is 536 deprecated in favor of tunnelInetConfigID." 537 ::= { tunnelConfigEntry 4 } 539 tunnelConfigIfIndex OBJECT-TYPE 540 SYNTAX InterfaceIndexOrZero 541 MAX-ACCESS read-only 542 STATUS deprecated 543 DESCRIPTION 544 "If the value of tunnelConfigStatus for this row is 545 active, then this object contains the value of ifIndex 546 corresponding to the tunnel interface. A value of 0 547 is not legal in the active state, and means that the 548 interface index has not yet been assigned. 550 Since this object does not support IPv6, it is 552 Draft Inet Tunnel MIB August 2004 554 deprecated in favor of tunnelInetConfigIfIndex." 555 ::= { tunnelConfigEntry 5 } 557 tunnelConfigStatus OBJECT-TYPE 558 SYNTAX RowStatus 559 MAX-ACCESS read-create 560 STATUS deprecated 561 DESCRIPTION 562 "The status of this row, by which new entries may be 563 created, or old entries deleted from this table. The 564 agent need not support setting this object to 565 createAndWait or notInService since there are no other 566 writable objects in this table, and writable objects 567 in rows of corresponding tables such as the 568 tunnelIfTable may be modified while this row is 569 active. 571 To create a row in this table for an encapsulation 572 method which does not support multiple parallel 573 tunnels with the same endpoints, the management 574 station should simply use a tunnelConfigID of 1, and 575 set tunnelConfigStatus to createAndGo. For 576 encapsulation methods such as L2F which allow multiple 577 parallel tunnels, the management station may select a 578 pseudo-random number to use as the tunnelConfigID and 579 set tunnelConfigStatus to createAndGo. In the event 580 that this ID is already in use and an 581 inconsistentValue is returned in response to the set 582 operation, the management station should simply select 583 a new pseudo-random number and retry the operation. 585 Creating a row in this table will cause an interface 586 index to be assigned by the agent in an 587 implementation-dependent manner, and corresponding 588 rows will be instantiated in the ifTable and the 589 tunnelIfTable. The status of this row will become 590 active as soon as the agent assigns the interface 591 index, regardless of whether the interface is 592 operationally up. 594 Deleting a row in this table will likewise delete the 595 corresponding row in the ifTable and in the 596 tunnelIfTable. 598 Since this object does not support IPv6, it is 600 Draft Inet Tunnel MIB August 2004 602 deprecated in favor of tunnelInetConfigStatus." 603 ::= { tunnelConfigEntry 6 } 605 tunnelInetConfigTable OBJECT-TYPE 606 SYNTAX SEQUENCE OF TunnelInetConfigEntry 607 MAX-ACCESS not-accessible 608 STATUS current 609 DESCRIPTION 610 "The (conceptual) table containing information on 611 configured tunnels. This table can be used to map a 612 set of tunnel endpoints to the associated ifIndex 613 value. It can also be used for row creation. Note 614 that every row in the tunnelIfTable with a fixed 615 destination address should have a corresponding row in 616 the tunnelInetConfigTable, regardless of whether it 617 was created via SNMP." 618 ::= { tunnel 3 } 620 tunnelInetConfigEntry OBJECT-TYPE 621 SYNTAX TunnelInetConfigEntry 622 MAX-ACCESS not-accessible 623 STATUS current 624 DESCRIPTION 625 "An entry (conceptual row) containing the information 626 on a particular configured tunnel. Note that there is 627 a 128 subid maximum for object OIDs. Implementers 628 need to be aware that if the total number of octets in 629 tunnelInetConfigLocalAddress and 630 tunnelInetConfigRemoteAddress exceeds 110 then OIDs of 631 column instances in this table will have more than 128 632 sub-identifiers and cannot be accessed using SNMPv1, 633 SNMPv2c, or SNMPv3. In practice this is not expected 634 to be a problem since IPv4 and IPv6 addresses will not 635 cause the limit to be reached, but if other types are 636 supported by an agent, care must be taken to ensure 637 that the sum of the lengths do not cause the limit to 638 be exceeded." 639 INDEX { tunnelInetConfigAddressType, 640 tunnelInetConfigLocalAddress, 641 tunnelInetConfigRemoteAddress, 642 tunnelInetConfigEncapsMethod, 643 tunnelInetConfigID } 644 ::= { tunnelInetConfigTable 1 } 646 TunnelInetConfigEntry ::= SEQUENCE { 647 Draft Inet Tunnel MIB August 2004 649 tunnelInetConfigAddressType InetAddressType, 650 tunnelInetConfigLocalAddress InetAddress, 651 tunnelInetConfigRemoteAddress InetAddress, 652 tunnelInetConfigEncapsMethod IANAtunnelType, 653 tunnelInetConfigID Integer32, 654 tunnelInetConfigIfIndex InterfaceIndexOrZero, 655 tunnelInetConfigStatus RowStatus, 656 tunnelInetConfigStorageType StorageType 657 } 659 tunnelInetConfigAddressType OBJECT-TYPE 660 SYNTAX InetAddressType 661 MAX-ACCESS not-accessible 662 STATUS current 663 DESCRIPTION 664 "The address type over which the tunnel encapsulates 665 packets." 666 ::= { tunnelInetConfigEntry 1 } 668 tunnelInetConfigLocalAddress OBJECT-TYPE 669 SYNTAX InetAddress 670 MAX-ACCESS not-accessible 671 STATUS current 672 DESCRIPTION 673 "The address of the local endpoint of the tunnel, or 674 0.0.0.0 (for IPv4) or :: (for IPv6) if the device is 675 free to choose any of its addresses at tunnel 676 establishment time." 677 ::= { tunnelInetConfigEntry 2 } 679 tunnelInetConfigRemoteAddress OBJECT-TYPE 680 SYNTAX InetAddress 681 MAX-ACCESS not-accessible 682 STATUS current 683 DESCRIPTION 684 "The address of the remote endpoint of the tunnel." 685 ::= { tunnelInetConfigEntry 3 } 687 tunnelInetConfigEncapsMethod OBJECT-TYPE 688 SYNTAX IANAtunnelType 689 MAX-ACCESS not-accessible 690 STATUS current 691 DESCRIPTION 692 "The encapsulation method used by the tunnel." 693 ::= { tunnelInetConfigEntry 4 } 695 Draft Inet Tunnel MIB August 2004 697 tunnelInetConfigID OBJECT-TYPE 698 SYNTAX Integer32 (1..2147483647) 699 MAX-ACCESS not-accessible 700 STATUS current 701 DESCRIPTION 702 "An identifier used to distinguish between multiple 703 tunnels of the same encapsulation method, with the 704 same endpoints. If the encapsulation protocol only 705 allows one tunnel per set of endpoint addresses (such 706 as for GRE or IP-in-IP), the value of this object is 707 1. For encapsulation methods (such as L2F) which 708 allow multiple parallel tunnels, the manager is 709 responsible for choosing any ID which does not 710 conflict with an existing row, such as choosing a 711 random number." 712 ::= { tunnelInetConfigEntry 5 } 714 tunnelInetConfigIfIndex OBJECT-TYPE 715 SYNTAX InterfaceIndexOrZero 716 MAX-ACCESS read-only 717 STATUS current 718 DESCRIPTION 719 "If the value of tunnelInetConfigStatus for this row 720 is active, then this object contains the value of 721 ifIndex corresponding to the tunnel interface. A 722 value of 0 is not legal in the active state, and means 723 that the interface index has not yet been assigned." 724 ::= { tunnelInetConfigEntry 6 } 726 tunnelInetConfigStatus OBJECT-TYPE 727 SYNTAX RowStatus 728 MAX-ACCESS read-create 729 STATUS current 730 DESCRIPTION 731 "The status of this row, by which new entries may be 732 created, or old entries deleted from this table. The 733 agent need not support setting this object to 734 createAndWait or notInService since there are no other 735 writable objects in this table, and writable objects 736 in rows of corresponding tables such as the 737 tunnelIfTable may be modified while this row is 738 active. 740 To create a row in this table for an encapsulation 741 method which does not support multiple parallel 743 Draft Inet Tunnel MIB August 2004 745 tunnels with the same endpoints, the management 746 station should simply use a tunnelInetConfigID of 1, 747 and set tunnelInetConfigStatus to createAndGo. For 748 encapsulation methods such as L2F which allow multiple 749 parallel tunnels, the management station may select a 750 pseudo-random number to use as the tunnelInetConfigID 751 and set tunnelInetConfigStatus to createAndGo. In the 752 event that this ID is already in use and an 753 inconsistentValue is returned in response to the set 754 operation, the management station should simply select 755 a new pseudo-random number and retry the operation. 757 Creating a row in this table will cause an interface 758 index to be assigned by the agent in an 759 implementation-dependent manner, and corresponding 760 rows will be instantiated in the ifTable and the 761 tunnelIfTable. The status of this row will become 762 active as soon as the agent assigns the interface 763 index, regardless of whether the interface is 764 operationally up. 766 Deleting a row in this table will likewise delete the 767 corresponding row in the ifTable and in the 768 tunnelIfTable." 769 ::= { tunnelInetConfigEntry 7 } 771 tunnelInetConfigStorageType OBJECT-TYPE 772 SYNTAX StorageType 773 MAX-ACCESS read-create 774 STATUS current 775 DESCRIPTION 776 "The storage type of this row. If the row is 777 permanent(4), no objects in the row need be writable." 778 ::= { tunnelInetConfigEntry 8 } 780 -- conformance information 782 tunnelMIBConformance 783 OBJECT IDENTIFIER ::= { tunnelMIB 2 } 784 tunnelMIBCompliances 785 OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 } 786 tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 } 788 -- compliance statements 789 Draft Inet Tunnel MIB August 2004 791 tunnelMIBCompliance MODULE-COMPLIANCE 792 STATUS deprecated 793 DESCRIPTION 794 "The (deprecated) IPv4-only compliance statement for 795 the IP Tunnel MIB. 797 This is deprecated in favor of 798 tunnelMIBInetReadWriteCompliance and 799 tunnelMIBInetReadOnlyCompliance." 800 MODULE -- this module 801 MANDATORY-GROUPS { tunnelMIBBasicGroup } 803 OBJECT tunnelIfHopLimit 804 MIN-ACCESS read-only 805 DESCRIPTION 806 "Write access is not required." 808 OBJECT tunnelIfTOS 809 MIN-ACCESS read-only 810 DESCRIPTION 811 "Write access is not required." 813 OBJECT tunnelConfigStatus 814 MIN-ACCESS read-only 815 DESCRIPTION 816 "Write access is not required." 817 ::= { tunnelMIBCompliances 1 } 819 tunnelMIBInetReadWriteCompliance MODULE-COMPLIANCE 820 STATUS current 821 DESCRIPTION 822 "The full compliance statement for the IP Tunnel MIB." 823 MODULE -- this module 824 MANDATORY-GROUPS { tunnelMIBInetGroup } 826 OBJECT tunnelIfAddressType 827 SYNTAX InetAddressType { ipv4(1), ipv6(2), 828 ipv4z(3), ipv6z(4) } 829 DESCRIPTION 830 "An implementation is only required to support IPv4 831 and/or IPv6 addresses. An implementation only needs to 832 support the addresses it actually supports on the 833 device." 835 OBJECT tunnelInetConfigStatus 837 Draft Inet Tunnel MIB August 2004 839 SYNTAX RowStatus { active(1) } 840 WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } 841 DESCRIPTION 842 "Support for createAndWait and notInService is not 843 required." 844 ::= { tunnelMIBCompliances 2 } 846 tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE 847 STATUS current 848 DESCRIPTION 849 "The read-only compliance statement for the IP Tunnel 850 MIB." 851 MODULE -- this module 852 MANDATORY-GROUPS { tunnelMIBInetGroup } 854 OBJECT tunnelIfHopLimit 855 MIN-ACCESS read-only 856 DESCRIPTION 857 "Write access is not required." 859 OBJECT tunnelIfTOS 860 MIN-ACCESS read-only 861 DESCRIPTION 862 "Write access is not required." 864 OBJECT tunnelIfFlowLabel 865 MIN-ACCESS read-only 866 DESCRIPTION 867 "Write access is not required." 869 OBJECT tunnelIfAddressType 870 SYNTAX InetAddressType { ipv4(1), ipv6(2), 871 ipv4z(3), ipv6z(4) } 872 MIN-ACCESS read-only 873 DESCRIPTION 874 "Write access is not required. 876 An implementation is only required to support IPv4 877 and/or IPv6 addresses. An implementation only needs to 878 support the addresses it actually supports on the 879 device." 881 OBJECT tunnelIfLocalInetAddress 882 MIN-ACCESS read-only 883 DESCRIPTION 885 Draft Inet Tunnel MIB August 2004 887 "Write access is not required." 889 OBJECT tunnelIfRemoteInetAddress 890 MIN-ACCESS read-only 891 DESCRIPTION 892 "Write access is not required." 894 OBJECT tunnelInetConfigStatus 895 SYNTAX RowStatus { active(1) } 896 MIN-ACCESS read-only 897 DESCRIPTION 898 "Write access is not required, and active is the only 899 status that needs to be supported." 901 OBJECT tunnelInetConfigStorageType 902 MIN-ACCESS read-only 903 DESCRIPTION 904 "Write access is not required." 905 ::= { tunnelMIBCompliances 3 } 907 -- units of conformance 909 tunnelMIBBasicGroup OBJECT-GROUP 910 OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress, 911 tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS, 912 tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus } 913 STATUS deprecated 914 DESCRIPTION 915 "A collection of objects to support basic management 916 of IPv4 Tunnels. Since this group cannot support 917 IPv6, it is deprecated in favor of 918 tunnelMIBInetGroup." 919 ::= { tunnelMIBGroups 1 } 921 tunnelMIBInetGroup OBJECT-GROUP 922 OBJECTS { tunnelIfAddressType, tunnelIfLocalInetAddress, 923 tunnelIfRemoteInetAddress, tunnelIfEncapsMethod, 924 tunnelIfHopLimit, tunnelIfTOS, tunnelIfFlowLabel, 925 tunnelIfSecurity, tunnelInetConfigIfIndex, 926 tunnelInetConfigStatus, tunnelInetConfigStorageType } 927 STATUS current 928 DESCRIPTION 929 "A collection of objects to support basic management 930 of IPv4 and IPv6 Tunnels." 931 ::= { tunnelMIBGroups 2 } 933 Draft Inet Tunnel MIB August 2004 935 END 937 5. IANA Considerations 939 This document introduces a new IANA-maintained textual convention 940 (TC) which is to be added to the IANAifType-MIB [IFTYPE]. The 941 initial version of this IANAtunnelType TC can be found in Appendix 942 A. The current version of the textual convention can be accessed 943 at http://www.iana.org/assignments/ianaiftype-mib 945 The policy for assigning new IANAtunnelType values is First Come 946 First Served, as defined in [RFC2434], just as it is for new 947 IANAifTypes values. The assignment policy for IANAtunnelType 948 values should always be identical to the policy for assigning 949 IANAifType values. 951 New types of tunnels over IPv4 or IPv6 should not be assigned 952 IANAifType values. Instead, they should be assigned 953 IANAtunnelType values and hence reuse the interface type 954 tunnel(131). (Note this restriction does not apply to "tunnels" 955 which are not over IPv4 or IPv6.) 957 Previously tunnel types which were not point-to-point tunnels were 958 problematic in that they could not be properly expressed in the 959 tunnel MIB, and hence were assigned IANAifType values. This 960 document now corrects this problem, and as a result, IANA should 961 deprecate the sixToFour(215) IANAifType value in favor of the 962 sixToFour(11) IANAtunnelType value. 964 6. Security Considerations 966 There are a number of management objects defined in this MIB 967 module with a MAX-ACCESS clause of read-write and/or read-create. 968 Such objects may be considered sensitive or vulnerable in some 969 network environments. The support for SET operations in a non- 970 secure environment without proper protection can have a negative 971 effect on network operations. 973 Unauthorized write access to any of the writable objects could 974 cause unauthorized creation and/or manipulation of tunnels, 975 resulting in a denial of service, or redirection of packets to an 976 arbitrary destination. 978 Draft Inet Tunnel MIB August 2004 980 Some of the readable objects in this MIB module (i.e., objects 981 with a MAX-ACCESS other than not-accessible) may be considered 982 sensitive or vulnerable in some network environments. It is thus 983 important to control even GET and/or NOTIFY access to these 984 objects and possibly to even encrypt the values of these objects 985 when sending them over the network via SNMP. 987 Unauthorized read access to tunnelIfLocalInetAddress, 988 tunnelIfRemoteInetAddress, tunnelIfLocalAddress, 989 tunnelIfRemoteAddress, or any object in the tunnelConfigTable or 990 tunnelInetConfigTable would reveal information about the tunnel 991 topology. 993 SNMP versions prior to SNMPv3 did not include adequate security. 994 Even if the network itself is secure (for example by using IPSec), 995 even then, there is no control as to who on the secure network is 996 allowed to access and GET/SET (read/change/create/delete) the 997 objects in this MIB module. 999 It is RECOMMENDED that implementers consider the security features 1000 as provided by the SNMPv3 framework (see [RFC3410], section 8), 1001 including full support for the SNMPv3 cryptographic mechanisms 1002 (for authentication and privacy). 1004 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1005 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1006 enable cryptographic security. It is then a customer/operator 1007 responsibility to ensure that the SNMP entity giving access to an 1008 instance of this MIB module is properly configured to give access 1009 to the objects only to those principals (users) that have 1010 legitimate rights to indeed GET or SET (change/create/delete) 1011 them. 1013 7. Changes since RFC 2667 1015 IPv4-specific objects were deprecated, including 1016 tunnelIfLocalAddress, tunnelIfRemoteAddress, the 1017 tunnelConfigTable, and the tunnelMIBBasicGroup. 1019 Added IP version-agnostic objects that should be used instead, 1020 including tunnelIfAddressType, tunnelIfLocalInetAddress, 1021 tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the 1022 tunnelIMIBInetGroup. 1024 Draft Inet Tunnel MIB August 2004 1026 The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress 1027 objects are read-write, rather than read-only. 1029 Updated DESCRIPTION clauses of existing version-agnostic objects 1030 (e.g., tunnelIfTOS) that contained IPv4-specific text to cover 1031 IPv6 as well. 1033 Added tunnelIfFlowLabel for tunnels over IPv6. 1035 The encapsulation method was previously an INTEGER type, and is 1036 now an IANA-maintained textual convention. 1038 8. Acknowledgements 1040 This MIB module was updated based on feedback from the IETF's 1041 Interfaces MIB (IF-MIB) and Point-to-Point Protocol Extensions 1042 (PPPEXT) Working Groups. Mike Heard also provided valuable MIB 1043 guidance on this version. 1045 9. Author's Address 1047 Dave Thaler 1048 Microsoft Corporation 1049 One Microsoft Way 1050 Redmond, WA 98052-6399 1052 Phone: +1 425 703 8835 1053 EMail: dthaler@microsoft.com 1055 10. Normative References 1057 [IFTYPE] Internet Assigned Numbers Authority, "IANAifType-MIB", 1058 http://www.iana.org/assignments/ianaiftype-mib 1060 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 1061 an IANA Considerations Section in RFCs", RFC 2434, 1062 October 1998. 1064 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1065 J., Rose, M. and S. Waldbusser, "Structure of 1066 Management Information Version 2 (SMIv2)", STD 58, RFC 1067 2578, April 1999. 1069 Draft Inet Tunnel MIB August 2004 1071 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1072 J., Rose, M. and S. Waldbusser, "Textual Conventions 1073 for SMIv2", STD 58, RFC 2579, April 1999. 1075 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1076 J., Rose, M. and S. Waldbusser, "Conformance 1077 Statements for SMIv2", STD 58, RFC 2580, April 1999. 1079 [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces 1080 Group MIB", RFC 2863, June 2000. 1082 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. 1083 Schoenwaelder, "Textual Conventions for Internet 1084 Network Addresses", RFC 3291, May 2002. 1086 [RFC3595] B. Wijnen, "Textual Conventions for IPv6 Flow Label", 1087 RFC 3595, September 2003. 1089 11. Informative References 1091 [RFC1234] D. Provan, "Tunneling IPX Traffic through IP 1092 Networks", RFC 1234, June 1991. 1094 [RFC1241] Woodburn, R. and D. Mills, "A Scheme for an Internet 1095 Encapsulation Protocol: Version 1", RFC 1241, July 1096 1991. 1098 [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, 1099 "Generic Routing Encapsulation (GRE)", RFC 1701, 1100 October 1994. 1102 [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, 1103 "Generic Routing Encapsulation over IPv4 networks", 1104 RFC 1702, October 1994. 1106 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1107 October 1996. 1109 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 1110 2004, October 1996. 1112 [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - 1113 ATMP", RFC 2107, February 1997. 1115 Draft Inet Tunnel MIB August 2004 1117 [RFC2341] Valencia, A., Littlewood, M. and T. Kolar. "Cisco 1118 Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1119 1998. 1121 [RFC2401] R. Atkinson, "Security architecture for the internet 1122 protocol", RFC 2401, November 1998. 1124 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black. 1125 "Definition of the Differentiated Services Field (DS 1126 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1127 December 1998. 1129 [RFC2637] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little, 1130 W. and G. Zorn, "Point-to-Point Tunneling Protocol", 1131 RFC 2637, July 1999. 1133 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., 1134 Zorn, G. and B. Palter, "Layer Two Tunneling Protocol 1135 "L2TP"", RFC 2661, August 1999. 1137 [RFC2893] Gilligan, R. and E. Nordmark. "Transition Mechanisms 1138 for IPv6 Hosts and Routers", RFC 2893, August 2000. 1140 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1141 "Introduction and Applicability Statements for 1142 Internet-Standard Management Framework", RFC 3410, 1143 December 2002. 1145 12. Appendix A: IANA Tunnel Type TC 1147 This appendix defines the initial content of the IANAtunnelType 1148 textual convention which should appear in the IANAifType-MIB. 1150 IANAtunnelType ::= TEXTUAL-CONVENTION 1151 STATUS current 1152 DESCRIPTION 1153 "The encapsulation method used by a tunnel. The value 1154 direct indicates that a packet is encapsulated 1155 directly within a normal IP header, with no 1156 intermediate header, and unicast to the remote tunnel 1157 endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC 1158 1933 IPv6-in-IPv4 tunnel). The value minimal indicates 1159 that a Minimal Forwarding Header (RFC 2004) is 1160 inserted between the outer header and the payload 1162 Draft Inet Tunnel MIB August 2004 1164 packet. The value UDP indicates that the payload 1165 packet is encapsulated within a normal UDP packet 1166 (e.g., RFC 1234). 1168 The values sixToFour, sixOverFour, and isatap 1169 indicates that an IPv6 packet is encapsulated directly 1170 within an IPv4 header, with no intermediate header, 1171 and unicast to the destination determined by the 6to4, 1172 6over4, or ISATAP protocol. 1174 The remaining protocol-specific values indicate that a 1175 header of the protocol of that name is inserted 1176 between the outer header and the payload header." 1177 SYNTAX INTEGER { 1178 other(1), -- none of the following 1179 direct(2), -- no intermediate header 1180 gre(3), -- GRE encapsulation 1181 minimal(4), -- Minimal encapsulation 1182 l2tp(5), -- L2TP encapsulation 1183 pptp(6), -- PPTP encapsulation 1184 l2f(7), -- L2F encapsulation 1185 udp(8), -- UDP encapsulation 1186 atmp(9), -- ATMP encapsulation 1187 msdp(10), -- MSDP encapsulation 1188 sixToFour(11), -- 6to4 encapsulation 1189 sixOverFour(12), -- 6over4 encapsulation 1190 isatap(13), -- ISATAP encapsulation 1191 teredo(14) -- Teredo encapsulation 1192 } 1194 13. Full Copyright Statement 1196 Copyright (C) The Internet Society (2004). This document is 1197 subject to the rights, licenses and restrictions contained in BCP 1198 78, and except as set forth therein, the authors retain all their 1199 rights. 1201 This document and the information contained herein are provided on 1202 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1203 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1204 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1205 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1206 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1207 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1208 Draft Inet Tunnel MIB August 2004 1210 PARTICULAR PURPOSE. 1212 14. Intellectual Property 1214 The IETF takes no position regarding the validity or scope of any 1215 intellectual property or other rights that might be claimed to 1216 pertain to the implementation or use of the technology described 1217 in this document or the extent to which any license under such 1218 rights might or might not be available; neither does it represent 1219 that it has made any effort to identify any such rights. 1220 Information on the IETF's procedures with respect to rights in 1221 standards-track and standards-related documentation can be found 1222 in BCP-11. Copies of claims of rights made available for 1223 publication and any assurances of licenses to be made available, 1224 or the result of an attempt made to obtain a general license or 1225 permission for the use of such proprietary rights by implementors 1226 or users of this specification can be obtained from the IETF 1227 Secretariat. 1229 The IETF invites any interested party to bring to its attention 1230 any copyrights, patents or patent applications, or other 1231 proprietary rights which may cover technology that may be required 1232 to practice this standard. Please address the information to the 1233 IETF Executive Director.