idnits 2.17.1 draft-ietf-ipv6-inet-tunnel-mib-03.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1230. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 35), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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 1017: '...It is RECOMMENDED that implementers co...' RFC 2119 keyword, line 1023: '... 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 (October 2004) is 7133 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 151 == Missing Reference: 'RFC3579' is mentioned on line 185, but not defined == Unused Reference: 'RFC2473' is defined on line 1079, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IFTYPE' ** 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: 14 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 April 2005 October 2004 6 IP Tunnel MIB 7 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been 13 disclosed, or will be disclosed, and any of which I become aware 14 will be disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than a "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Draft Inet Tunnel MIB October 2004 39 Abstract 41 This memo defines a Management Information Base (MIB) module for 42 use with network management protocols in the Internet community. 43 In particular, it describes managed objects used for managing 44 tunnels of any type over IPv4 and IPv6 networks. Extension MIB 45 modules may be designed for managing protocol-specific objects. 46 Likewise, extension MIB modules may be designed for managing 47 security-specific objects. This MIB module does not support 48 tunnels over non-IP networks. Management of such tunnels may be 49 supported by other MIB modules. 51 This memo obsoletes RFC 2667. 53 1. Introduction 55 Over the past several years, there have been a number of 56 "tunneling" protocols specified by the IETF (see [RFC1241] for an 57 early discussion of the model and examples). This document 58 describes a Management Information Base (MIB) module used for 59 managing tunnels of any type over IPv4 and IPv6 networks, 60 including GRE [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal 61 Encapsulation [RFC2004], L2TP [RFC2661], PPTP [RFC2637], L2F 62 [RFC2341], UDP (e.g., [RFC1234]), ATMP [RFC2107], and IPv6-in-IPv4 63 [RFC2893] tunnels, among others. 65 Extension MIB modules may be designed for managing protocol- 66 specific objects. Likewise, extension MIB modules may be designed 67 for managing security-specific objects (e.g., IPsec [RFC2401]), 68 and traffic conditioner [RFC2474] objects. 70 2. The Internet-Standard Management Framework 72 For a detailed overview of the documents that describe the current 73 Internet-Standard Management Framework, please refer to section 7 74 of RFC 3410 [RFC3410]. 76 Managed objects are accessed via a virtual information store, 77 termed the Management Information Base or MIB. MIB objects are 78 generally accessed through the Simple Network Management Protocol 79 (SNMP). Objects in the MIB are defined using the mechanisms 80 defined in the Structure of Management Information (SMI). This 81 memo specifies a MIB module that is compliant to the SMIv2, which 82 Draft Inet Tunnel MIB October 2004 84 is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 85 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 87 3. Overview 89 This MIB module contains two current tables and one deprecated 90 table. The current tables are: 92 o the Tunnel Interface Table, containing information on the 93 tunnels known to a router; and 95 o the Tunnel Inet Config Table, which can be used for dynamic 96 creation of tunnels, and also provides a mapping from 97 endpoint addresses to the current interface index value. 99 The version of this MIB module that appeared in RFC 2667 contained 100 the Tunnel Config Table, which mapped IPv4 endpoint addresses to 101 interface indexes. It is now deprecated in favor of the Tunnel 102 Inet Config Table. 104 3.1. Relationship to the Interfaces MIB 106 This section clarifies the relationship of this MIB module to the 107 Interfaces MIB [RFC2863]. Several areas of correlation are 108 addressed in the following subsections. The implementor is 109 referred to the Interfaces MIB document in order to understand the 110 general intent of these areas. 112 3.1.1. Layering Model 114 Each logical interface (physical or virtual) has an ifEntry in the 115 Interfaces MIB [RFC2863]. Tunnels are handled by creating a 116 logical interface (ifEntry) for each tunnel. These are then 117 correlated, using the ifStack table of the Interfaces MIB, to 118 those interfaces on which the local IPv4 or IPv6 addresses of the 119 tunnels are configured. The basic model, therefore, looks 120 something like this (for example): 122 | | | | | | 123 +--+ +---+ +--+ +---+ | | 124 |IP-in-IP| | GRE | | | 125 | tunnel | | tunnel | | | 127 Draft Inet Tunnel MIB October 2004 129 +--+ +---+ +--+ +---+ | | 130 | | | | | | <== attachment to underlying 131 +--+ +---------+ +----------+ +--+ interfaces, to be provided 132 | Physical interface | by ifStack table 133 +--------------------------------+ 135 3.1.2. ifRcvAddressTable 137 The ifRcvAddressTable usage can be defined in the MIB modules 138 defining the encapsulation below the network layer, and holds the 139 local IP addresses on which decapsulation will occur. For 140 example, if IP-in-IP encapsulation is being used, the 141 ifRcvAddressTable can be defined by IP- in-IP. If it is not 142 specified, the default is that one entry will exist for the tunnel 143 interface, where ifRcvAddressAddress contains the local IP address 144 used for encapsulation/decapsulation (i.e., 145 tunnelIfLocalInetAddress in the Tunnel Interface Table). 147 3.1.3. ifEntry 149 IfEntries are defined in the MIB modules defining the 150 encapsulation below the network layer. For example, if IP-in-IP 151 encapsulation [20] is being used, the ifEntry is defined by IP-in- 152 IP. 154 The ifType of a tunnel should be set to "tunnel" (131). An entry 155 in the IP Tunnel MIB module will exist for every ifEntry with this 156 ifType. An implementation of the IP Tunnel MIB module may allow 157 ifEntries to be created via the tunnelConfigTable. Creating a 158 tunnel will also add an entry in the ifTable and in the 159 tunnelIfTable, and deleting a tunnel will likewise delete the 160 entry in the ifTable and the tunnelIfTable. 162 The use of two different tables in this MIB module was an 163 important design decision. Traditionally, ifIndex values are 164 chosen by agents, and are permitted to change across restarts. 165 Allowing row creation directly in the Tunnel Interface Table, 166 indexed by ifIndex, would complicate row creation and/or cause 167 interoperability problems (if each agent had special restrictions 168 on ifIndex). Instead, a separate table is used which is indexed 169 only by objects over which the manager has control. Namely, these 170 are the addresses of the tunnel endpoints and the encapsulation 171 protocol. Finally, an additional manager- chosen ID is used in 172 Draft Inet Tunnel MIB October 2004 174 the index to support protocols such as L2F which allow multiple 175 tunnels between the same endpoints. 177 4. Definitions 179 TUNNEL-MIB DEFINITIONS ::= BEGIN 181 IMPORTS 182 MODULE-IDENTITY, OBJECT-TYPE, transmission, 183 Integer32, IpAddress FROM SNMPv2-SMI -- [RFC2578] 185 RowStatus, StorageType FROM SNMPv2-TC -- [RFC3579] 187 MODULE-COMPLIANCE, 188 OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] 190 InetAddressType, 191 InetAddress FROM INET-ADDRESS-MIB -- [RFC3291] 193 IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB -- [RFC3595] 195 ifIndex, 196 InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] 198 IANAtunnelType FROM IANAifType-MIB; -- [IFTYPE] 200 tunnelMIB MODULE-IDENTITY 201 LAST-UPDATED "200410161200Z" -- October 16, 2004 202 ORGANIZATION "IETF IP Version 6 (IPv6) Working Group" 203 CONTACT-INFO 204 " Dave Thaler 205 Microsoft Corporation 206 One Microsoft Way 207 Redmond, WA 98052-6399 208 EMail: dthaler@microsoft.com" 209 DESCRIPTION 210 "The MIB module for management of IP Tunnels, 211 independent of the specific encapsulation scheme in 212 use. 214 Copyright (C) The Internet Society (date). This 215 version of this MIB module is part of RFC yyyy; see 216 the RFC itself for full legal notices." 217 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 218 Draft Inet Tunnel MIB October 2004 220 REVISION "200410161200Z" -- October 16, 2004 221 DESCRIPTION 222 "IPv4-specific objects were deprecated, including 223 tunnelIfLocalAddress, tunnelIfRemoteAddress, the 224 tunnelConfigTable, and the tunnelMIBBasicGroup. 226 Added IP version-agnostic objects that should be used 227 instead, including tunnelIfAddressType, 228 tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, 229 the tunnelInetConfigTable, and the 230 tunnelIMIBInetGroup. 232 The new tunnelIfLocalInetAddress and 233 tunnelIfRemoteInetAddress objects are read-write, 234 rather than read-only. 236 Updated DESCRIPTION clauses of existing version- 237 agnostic objects (e.g., tunnelIfTOS) that contained 238 IPv4-specific text to cover IPv6 as well. 240 Added tunnelIfFlowLabel for tunnels over IPv6. 242 The encapsulation method was previously an INTEGER 243 type, and is now an IANA-maintained textual 244 convention. 246 Published as RFC yyyy." 247 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 248 REVISION "199908241200Z" -- August 24, 1999 249 DESCRIPTION 250 "Initial version, published as RFC 2667." 251 ::= { transmission 131 } 253 tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 } 255 tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 } 257 -- the IP Tunnel MIB-Group 258 -- 259 -- a collection of objects providing information about 260 -- IP Tunnels 262 tunnelIfTable OBJECT-TYPE 263 SYNTAX SEQUENCE OF TunnelIfEntry 264 MAX-ACCESS not-accessible 266 Draft Inet Tunnel MIB October 2004 268 STATUS current 269 DESCRIPTION 270 "The (conceptual) table containing information on 271 configured tunnels." 272 ::= { tunnel 1 } 274 tunnelIfEntry OBJECT-TYPE 275 SYNTAX TunnelIfEntry 276 MAX-ACCESS not-accessible 277 STATUS current 278 DESCRIPTION 279 "An entry (conceptual row) containing the information 280 on a particular configured tunnel." 281 INDEX { ifIndex } 282 ::= { tunnelIfTable 1 } 284 TunnelIfEntry ::= SEQUENCE { 285 tunnelIfLocalAddress IpAddress, -- deprecated 286 tunnelIfRemoteAddress IpAddress, -- deprecated 287 tunnelIfEncapsMethod IANAtunnelType, 288 tunnelIfHopLimit Integer32, 289 tunnelIfSecurity INTEGER, 290 tunnelIfTOS Integer32, 291 tunnelIfFlowLabel IPv6FlowLabelOrAny, 292 tunnelIfAddressType InetAddressType, 293 tunnelIfLocalInetAddress InetAddress, 294 tunnelIfRemoteInetAddress InetAddress, 295 tunnelIfEncapsLimit Integer32 296 } 298 tunnelIfLocalAddress OBJECT-TYPE 299 SYNTAX IpAddress 300 MAX-ACCESS read-only 301 STATUS deprecated 302 DESCRIPTION 303 "The address of the local endpoint of the tunnel 304 (i.e., the source address used in the outer IP 305 header), or 0.0.0.0 if unknown or if the tunnel is 306 over IPv6. 308 Since this object does not support IPv6, it is 309 deprecated in favor of tunnelIfLocalInetAddress." 310 ::= { tunnelIfEntry 1 } 312 tunnelIfRemoteAddress OBJECT-TYPE 313 Draft Inet Tunnel MIB October 2004 315 SYNTAX IpAddress 316 MAX-ACCESS read-only 317 STATUS deprecated 318 DESCRIPTION 319 "The address of the remote endpoint of the tunnel 320 (i.e., the destination address used in the outer IP 321 header), or 0.0.0.0 if unknown, or an IPv6 address, or 322 the tunnel is not a point-to-point link (e.g., if it 323 is a 6to4 tunnel). 325 Since this object does not support IPv6, it is 326 deprecated in favor of tunnelIfRemoteInetAddress." 327 ::= { tunnelIfEntry 2 } 329 tunnelIfEncapsMethod OBJECT-TYPE 330 SYNTAX IANAtunnelType 331 MAX-ACCESS read-only 332 STATUS current 333 DESCRIPTION 334 "The encapsulation method used by the tunnel." 335 ::= { tunnelIfEntry 3 } 337 tunnelIfHopLimit OBJECT-TYPE 338 SYNTAX Integer32 (0 | 1..255) 339 MAX-ACCESS read-write 340 STATUS current 341 DESCRIPTION 342 "The IPv4 TTL or IPv6 Hop Limit to use in the outer IP 343 header. A value of 0 indicates that the value is 344 copied from the payload's header." 345 ::= { tunnelIfEntry 4 } 347 tunnelIfSecurity OBJECT-TYPE 348 SYNTAX INTEGER { 349 none(1), -- no security 350 ipsec(2), -- IPsec security 351 other(3) 352 } 353 MAX-ACCESS read-only 354 STATUS current 355 DESCRIPTION 356 "The method used by the tunnel to secure the outer IP 357 header. The value ipsec indicates that IPsec is used 358 between the tunnel endpoints for authentication or 359 encryption or both. More specific security-related 361 Draft Inet Tunnel MIB October 2004 363 information may be available in a MIB module for the 364 security protocol in use." 365 ::= { tunnelIfEntry 5 } 367 tunnelIfTOS OBJECT-TYPE 368 SYNTAX Integer32 (-2..63) 369 MAX-ACCESS read-write 370 STATUS current 371 DESCRIPTION 372 "The method used to set the high 6 bits (the 373 differentiated services codepoint) of the IPv4 TOS or 374 IPv6 Traffic Class in the outer IP header. A value of 375 -1 indicates that the bits are copied from the 376 payload's header. A value of -2 indicates that a 377 traffic conditioner is invoked and more information 378 may be available in a traffic conditioner MIB module. 379 A value between 0 and 63 inclusive indicates that the 380 bit field is set to the indicated value. 382 Note: instead of the name tunnelIfTOS, a better name 383 would have been tunnelIfDSCPMethod, but the existing 384 name appeared in RFC 2776 and existing objects cannot 385 be renamed." 386 ::= { tunnelIfEntry 6 } 388 tunnelIfFlowLabel OBJECT-TYPE 389 SYNTAX IPv6FlowLabelOrAny 390 MAX-ACCESS read-write 391 STATUS current 392 DESCRIPTION 393 "The method used to set the IPv6 Flow Label value. 394 This object need not be present in rows where 395 tunnelIfAddressType indicates the tunnel is not over 396 IPv6. A value of -1 indicates that a traffic 397 conditioner is invoked and more information may be 398 available in a traffic conditioner MIB. Any other 399 value indicates that the Flow Label field is set to 400 the indicated value." 401 ::= { tunnelIfEntry 7 } 403 tunnelIfAddressType OBJECT-TYPE 404 SYNTAX InetAddressType 405 MAX-ACCESS read-write 406 STATUS current 407 DESCRIPTION 409 Draft Inet Tunnel MIB October 2004 411 "The type of address in the corresponding 412 tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress 413 objects." 414 ::= { tunnelIfEntry 8 } 416 tunnelIfLocalInetAddress OBJECT-TYPE 417 SYNTAX InetAddress 418 MAX-ACCESS read-write 419 STATUS current 420 DESCRIPTION 421 "The address of the local endpoint of the tunnel 422 (i.e., the source address used in the outer IP 423 header). If the address is unknown, the value is 424 0.0.0.0 for IPv4 or :: for IPv6. The type of this 425 object is given by tunnelIfAddressType." 426 ::= { tunnelIfEntry 9 } 428 tunnelIfRemoteInetAddress OBJECT-TYPE 429 SYNTAX InetAddress 430 MAX-ACCESS read-write 431 STATUS current 432 DESCRIPTION 433 "The address of the remote endpoint of the tunnel 434 (i.e., the destination address used in the outer IP 435 header). If the address is unknown or the tunnel is 436 not a point-to-point link (e.g., if it is a 6to4 437 tunnel), the value is 0.0.0.0 for tunnels over IPv4 or 438 :: for tunnels over IPv6. The type of this object is 439 given by tunnelIfAddressType." 440 ::= { tunnelIfEntry 10 } 442 tunnelIfEncapsLimit OBJECT-TYPE 443 SYNTAX Integer32 (-1 | 0..255) 444 MAX-ACCESS read-write 445 STATUS current 446 DESCRIPTION 447 "The maximum number of additional encapsulations 448 permitted for packets undergoing encapsulation at this 449 node. A value of -1 indicates that no limit is 450 present (except as a result of the packet size)." 451 REFERENCE "RFC 2473, section 4.1.1" 452 ::= { tunnelIfEntry 11 } 454 tunnelConfigTable OBJECT-TYPE 455 SYNTAX SEQUENCE OF TunnelConfigEntry 457 Draft Inet Tunnel MIB October 2004 459 MAX-ACCESS not-accessible 460 STATUS deprecated 461 DESCRIPTION 462 "The (conceptual) table containing information on 463 configured tunnels. This table can be used to map a 464 set of tunnel endpoints to the associated ifIndex 465 value. It can also be used for row creation. Note 466 that every row in the tunnelIfTable with a fixed IPv4 467 destination address should have a corresponding row in 468 the tunnelConfigTable, regardless of whether it was 469 created via SNMP. 471 Since this table does not support IPv6, it is 472 deprecated in favor of tunnelInetConfigTable." 473 ::= { tunnel 2 } 475 tunnelConfigEntry OBJECT-TYPE 476 SYNTAX TunnelConfigEntry 477 MAX-ACCESS not-accessible 478 STATUS deprecated 479 DESCRIPTION 480 "An entry (conceptual row) containing the information 481 on a particular configured tunnel. 483 Since this entry does not support IPv6, it is 484 deprecated in favor of tunnelInetConfigEntry." 485 INDEX { tunnelConfigLocalAddress, 486 tunnelConfigRemoteAddress, 487 tunnelConfigEncapsMethod, 488 tunnelConfigID } 489 ::= { tunnelConfigTable 1 } 491 TunnelConfigEntry ::= SEQUENCE { 492 tunnelConfigLocalAddress IpAddress, 493 tunnelConfigRemoteAddress IpAddress, 494 tunnelConfigEncapsMethod IANAtunnelType, 495 tunnelConfigID Integer32, 496 tunnelConfigIfIndex InterfaceIndexOrZero, 497 tunnelConfigStatus RowStatus 498 } 500 tunnelConfigLocalAddress OBJECT-TYPE 501 SYNTAX IpAddress 502 MAX-ACCESS not-accessible 503 STATUS deprecated 505 Draft Inet Tunnel MIB October 2004 507 DESCRIPTION 508 "The address of the local endpoint of the tunnel, or 509 0.0.0.0 if the device is free to choose any of its 510 addresses at tunnel establishment time. 512 Since this object does not support IPv6, it is 513 deprecated in favor of tunnelInetConfigLocalAddress." 514 ::= { tunnelConfigEntry 1 } 516 tunnelConfigRemoteAddress OBJECT-TYPE 517 SYNTAX IpAddress 518 MAX-ACCESS not-accessible 519 STATUS deprecated 520 DESCRIPTION 521 "The address of the remote endpoint of the tunnel. 523 Since this object does not support IPv6, it is 524 deprecated in favor of tunnelInetConfigRemoteAddress." 525 ::= { tunnelConfigEntry 2 } 527 tunnelConfigEncapsMethod OBJECT-TYPE 528 SYNTAX IANAtunnelType 529 MAX-ACCESS not-accessible 530 STATUS deprecated 531 DESCRIPTION 532 "The encapsulation method used by the tunnel. 534 Since this object does not support IPv6, it is 535 deprecated in favor of tunnelInetConfigEncapsMethod." 536 ::= { tunnelConfigEntry 3 } 538 tunnelConfigID OBJECT-TYPE 539 SYNTAX Integer32 (1..2147483647) 540 MAX-ACCESS not-accessible 541 STATUS deprecated 542 DESCRIPTION 543 "An identifier used to distinguish between multiple 544 tunnels of the same encapsulation method, with the 545 same endpoints. If the encapsulation protocol only 546 allows one tunnel per set of endpoint addresses (such 547 as for GRE or IP-in-IP), the value of this object is 548 1. For encapsulation methods (such as L2F) which 549 allow multiple parallel tunnels, the manager is 550 responsible for choosing any ID which does not 551 conflict with an existing row, such as choosing a 553 Draft Inet Tunnel MIB October 2004 555 random number. 557 Since this object does not support IPv6, it is 558 deprecated in favor of tunnelInetConfigID." 559 ::= { tunnelConfigEntry 4 } 561 tunnelConfigIfIndex OBJECT-TYPE 562 SYNTAX InterfaceIndexOrZero 563 MAX-ACCESS read-only 564 STATUS deprecated 565 DESCRIPTION 566 "If the value of tunnelConfigStatus for this row is 567 active, then this object contains the value of ifIndex 568 corresponding to the tunnel interface. A value of 0 569 is not legal in the active state, and means that the 570 interface index has not yet been assigned. 572 Since this object does not support IPv6, it is 573 deprecated in favor of tunnelInetConfigIfIndex." 574 ::= { tunnelConfigEntry 5 } 576 tunnelConfigStatus OBJECT-TYPE 577 SYNTAX RowStatus 578 MAX-ACCESS read-create 579 STATUS deprecated 580 DESCRIPTION 581 "The status of this row, by which new entries may be 582 created, or old entries deleted from this table. The 583 agent need not support setting this object to 584 createAndWait or notInService since there are no other 585 writable objects in this table, and writable objects 586 in rows of corresponding tables such as the 587 tunnelIfTable may be modified while this row is 588 active. 590 To create a row in this table for an encapsulation 591 method which does not support multiple parallel 592 tunnels with the same endpoints, the management 593 station should simply use a tunnelConfigID of 1, and 594 set tunnelConfigStatus to createAndGo. For 595 encapsulation methods such as L2F which allow multiple 596 parallel tunnels, the management station may select a 597 pseudo-random number to use as the tunnelConfigID and 598 set tunnelConfigStatus to createAndGo. In the event 599 that this ID is already in use and an 601 Draft Inet Tunnel MIB October 2004 603 inconsistentValue is returned in response to the set 604 operation, the management station should simply select 605 a new pseudo-random number and retry the operation. 607 Creating a row in this table will cause an interface 608 index to be assigned by the agent in an 609 implementation-dependent manner, and corresponding 610 rows will be instantiated in the ifTable and the 611 tunnelIfTable. The status of this row will become 612 active as soon as the agent assigns the interface 613 index, regardless of whether the interface is 614 operationally up. 616 Deleting a row in this table will likewise delete the 617 corresponding row in the ifTable and in the 618 tunnelIfTable. 620 Since this object does not support IPv6, it is 621 deprecated in favor of tunnelInetConfigStatus." 622 ::= { tunnelConfigEntry 6 } 624 tunnelInetConfigTable OBJECT-TYPE 625 SYNTAX SEQUENCE OF TunnelInetConfigEntry 626 MAX-ACCESS not-accessible 627 STATUS current 628 DESCRIPTION 629 "The (conceptual) table containing information on 630 configured tunnels. This table can be used to map a 631 set of tunnel endpoints to the associated ifIndex 632 value. It can also be used for row creation. Note 633 that every row in the tunnelIfTable with a fixed 634 destination address should have a corresponding row in 635 the tunnelInetConfigTable, regardless of whether it 636 was created via SNMP." 637 ::= { tunnel 3 } 639 tunnelInetConfigEntry OBJECT-TYPE 640 SYNTAX TunnelInetConfigEntry 641 MAX-ACCESS not-accessible 642 STATUS current 643 DESCRIPTION 644 "An entry (conceptual row) containing the information 645 on a particular configured tunnel. Note that there is 646 a 128 subid maximum for object OIDs. Implementers 647 need to be aware that if the total number of octets in 649 Draft Inet Tunnel MIB October 2004 651 tunnelInetConfigLocalAddress and 652 tunnelInetConfigRemoteAddress exceeds 110 then OIDs of 653 column instances in this table will have more than 128 654 sub-identifiers and cannot be accessed using SNMPv1, 655 SNMPv2c, or SNMPv3. In practice this is not expected 656 to be a problem since IPv4 and IPv6 addresses will not 657 cause the limit to be reached, but if other types are 658 supported by an agent, care must be taken to ensure 659 that the sum of the lengths do not cause the limit to 660 be exceeded." 661 INDEX { tunnelInetConfigAddressType, 662 tunnelInetConfigLocalAddress, 663 tunnelInetConfigRemoteAddress, 664 tunnelInetConfigEncapsMethod, 665 tunnelInetConfigID } 666 ::= { tunnelInetConfigTable 1 } 668 TunnelInetConfigEntry ::= SEQUENCE { 669 tunnelInetConfigAddressType InetAddressType, 670 tunnelInetConfigLocalAddress InetAddress, 671 tunnelInetConfigRemoteAddress InetAddress, 672 tunnelInetConfigEncapsMethod IANAtunnelType, 673 tunnelInetConfigID Integer32, 674 tunnelInetConfigIfIndex InterfaceIndexOrZero, 675 tunnelInetConfigStatus RowStatus, 676 tunnelInetConfigStorageType StorageType 677 } 679 tunnelInetConfigAddressType OBJECT-TYPE 680 SYNTAX InetAddressType 681 MAX-ACCESS not-accessible 682 STATUS current 683 DESCRIPTION 684 "The address type over which the tunnel encapsulates 685 packets." 686 ::= { tunnelInetConfigEntry 1 } 688 tunnelInetConfigLocalAddress OBJECT-TYPE 689 SYNTAX InetAddress 690 MAX-ACCESS not-accessible 691 STATUS current 692 DESCRIPTION 693 "The address of the local endpoint of the tunnel, or 694 0.0.0.0 (for IPv4) or :: (for IPv6) if the device is 695 free to choose any of its addresses at tunnel 697 Draft Inet Tunnel MIB October 2004 699 establishment time." 700 ::= { tunnelInetConfigEntry 2 } 702 tunnelInetConfigRemoteAddress OBJECT-TYPE 703 SYNTAX InetAddress 704 MAX-ACCESS not-accessible 705 STATUS current 706 DESCRIPTION 707 "The address of the remote endpoint of the tunnel." 708 ::= { tunnelInetConfigEntry 3 } 710 tunnelInetConfigEncapsMethod OBJECT-TYPE 711 SYNTAX IANAtunnelType 712 MAX-ACCESS not-accessible 713 STATUS current 714 DESCRIPTION 715 "The encapsulation method used by the tunnel." 716 ::= { tunnelInetConfigEntry 4 } 718 tunnelInetConfigID OBJECT-TYPE 719 SYNTAX Integer32 (1..2147483647) 720 MAX-ACCESS not-accessible 721 STATUS current 722 DESCRIPTION 723 "An identifier used to distinguish between multiple 724 tunnels of the same encapsulation method, with the 725 same endpoints. If the encapsulation protocol only 726 allows one tunnel per set of endpoint addresses (such 727 as for GRE or IP-in-IP), the value of this object is 728 1. For encapsulation methods (such as L2F) which 729 allow multiple parallel tunnels, the manager is 730 responsible for choosing any ID which does not 731 conflict with an existing row, such as choosing a 732 random number." 733 ::= { tunnelInetConfigEntry 5 } 735 tunnelInetConfigIfIndex OBJECT-TYPE 736 SYNTAX InterfaceIndexOrZero 737 MAX-ACCESS read-only 738 STATUS current 739 DESCRIPTION 740 "If the value of tunnelInetConfigStatus for this row 741 is active, then this object contains the value of 742 ifIndex corresponding to the tunnel interface. A 743 value of 0 is not legal in the active state, and means 745 Draft Inet Tunnel MIB October 2004 747 that the interface index has not yet been assigned." 748 ::= { tunnelInetConfigEntry 6 } 750 tunnelInetConfigStatus OBJECT-TYPE 751 SYNTAX RowStatus 752 MAX-ACCESS read-create 753 STATUS current 754 DESCRIPTION 755 "The status of this row, by which new entries may be 756 created, or old entries deleted from this table. The 757 agent need not support setting this object to 758 createAndWait or notInService since there are no other 759 writable objects in this table, and writable objects 760 in rows of corresponding tables such as the 761 tunnelIfTable may be modified while this row is 762 active. 764 To create a row in this table for an encapsulation 765 method which does not support multiple parallel 766 tunnels with the same endpoints, the management 767 station should simply use a tunnelInetConfigID of 1, 768 and set tunnelInetConfigStatus to createAndGo. For 769 encapsulation methods such as L2F which allow multiple 770 parallel tunnels, the management station may select a 771 pseudo-random number to use as the tunnelInetConfigID 772 and set tunnelInetConfigStatus to createAndGo. In the 773 event that this ID is already in use and an 774 inconsistentValue is returned in response to the set 775 operation, the management station should simply select 776 a new pseudo-random number and retry the operation. 778 Creating a row in this table will cause an interface 779 index to be assigned by the agent in an 780 implementation-dependent manner, and corresponding 781 rows will be instantiated in the ifTable and the 782 tunnelIfTable. The status of this row will become 783 active as soon as the agent assigns the interface 784 index, regardless of whether the interface is 785 operationally up. 787 Deleting a row in this table will likewise delete the 788 corresponding row in the ifTable and in the 789 tunnelIfTable." 790 ::= { tunnelInetConfigEntry 7 } 792 Draft Inet Tunnel MIB October 2004 794 tunnelInetConfigStorageType OBJECT-TYPE 795 SYNTAX StorageType 796 MAX-ACCESS read-create 797 STATUS current 798 DESCRIPTION 799 "The storage type of this row. If the row is 800 permanent(4), no objects in the row need be writable." 801 ::= { tunnelInetConfigEntry 8 } 803 -- conformance information 805 tunnelMIBConformance 806 OBJECT IDENTIFIER ::= { tunnelMIB 2 } 807 tunnelMIBCompliances 808 OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 } 809 tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 } 811 -- compliance statements 813 tunnelMIBCompliance MODULE-COMPLIANCE 814 STATUS deprecated 815 DESCRIPTION 816 "The (deprecated) IPv4-only compliance statement for 817 the IP Tunnel MIB. 819 This is deprecated in favor of 820 tunnelMIBInetFullCompliance and 821 tunnelMIBInetReadOnlyCompliance." 822 MODULE -- this module 823 MANDATORY-GROUPS { tunnelMIBBasicGroup } 825 OBJECT tunnelIfHopLimit 826 MIN-ACCESS read-only 827 DESCRIPTION 828 "Write access is not required." 830 OBJECT tunnelIfTOS 831 MIN-ACCESS read-only 832 DESCRIPTION 833 "Write access is not required." 835 OBJECT tunnelConfigStatus 836 MIN-ACCESS read-only 837 DESCRIPTION 838 "Write access is not required." 840 Draft Inet Tunnel MIB October 2004 842 ::= { tunnelMIBCompliances 1 } 844 tunnelMIBInetFullCompliance MODULE-COMPLIANCE 845 STATUS current 846 DESCRIPTION 847 "The full compliance statement for the IP Tunnel MIB." 848 MODULE -- this module 849 MANDATORY-GROUPS { tunnelMIBInetGroup } 851 OBJECT tunnelIfAddressType 852 SYNTAX InetAddressType { ipv4(1), ipv6(2), 853 ipv4z(3), ipv6z(4) } 854 DESCRIPTION 855 "An implementation is only required to support IPv4 856 and/or IPv6 addresses. An implementation only needs to 857 support the addresses it actually supports on the 858 device." 859 ::= { tunnelMIBCompliances 2 } 861 tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE 862 STATUS current 863 DESCRIPTION 864 "The read-only compliance statement for the IP Tunnel 865 MIB." 866 MODULE -- this module 867 MANDATORY-GROUPS { tunnelMIBInetGroup } 869 OBJECT tunnelIfHopLimit 870 MIN-ACCESS read-only 871 DESCRIPTION 872 "Write access is not required." 874 OBJECT tunnelIfTOS 875 MIN-ACCESS read-only 876 DESCRIPTION 877 "Write access is not required." 879 OBJECT tunnelIfFlowLabel 880 MIN-ACCESS read-only 881 DESCRIPTION 882 "Write access is not required." 884 OBJECT tunnelIfAddressType 885 SYNTAX InetAddressType { ipv4(1), ipv6(2), 886 ipv4z(3), ipv6z(4) } 888 Draft Inet Tunnel MIB October 2004 890 MIN-ACCESS read-only 891 DESCRIPTION 892 "Write access is not required. 894 An implementation is only required to support IPv4 895 and/or IPv6 addresses. An implementation only needs to 896 support the addresses it actually supports on the 897 device." 899 OBJECT tunnelIfLocalInetAddress 900 MIN-ACCESS read-only 901 DESCRIPTION 902 "Write access is not required." 904 OBJECT tunnelIfRemoteInetAddress 905 MIN-ACCESS read-only 906 DESCRIPTION 907 "Write access is not required." 909 OBJECT tunnelIfEncapsLimit 910 MIN-ACCESS read-only 911 DESCRIPTION 912 "Write access is not required." 914 OBJECT tunnelInetConfigStatus 915 MIN-ACCESS read-only 916 DESCRIPTION 917 "Write access is not required, and active is the only 918 status that needs to be supported." 920 OBJECT tunnelInetConfigStorageType 921 MIN-ACCESS read-only 922 DESCRIPTION 923 "Write access is not required." 924 ::= { tunnelMIBCompliances 3 } 926 -- units of conformance 928 tunnelMIBBasicGroup OBJECT-GROUP 929 OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress, 930 tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS, 931 tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus } 932 STATUS deprecated 933 DESCRIPTION 934 "A collection of objects to support basic management 936 Draft Inet Tunnel MIB October 2004 938 of IPv4 Tunnels. Since this group cannot support 939 IPv6, it is deprecated in favor of 940 tunnelMIBInetGroup." 941 ::= { tunnelMIBGroups 1 } 943 tunnelMIBInetGroup OBJECT-GROUP 944 OBJECTS { tunnelIfAddressType, tunnelIfLocalInetAddress, 945 tunnelIfRemoteInetAddress, tunnelIfEncapsMethod, 946 tunnelIfEncapsLimit, 947 tunnelIfHopLimit, tunnelIfTOS, tunnelIfFlowLabel, 948 tunnelIfSecurity, tunnelInetConfigIfIndex, 949 tunnelInetConfigStatus, tunnelInetConfigStorageType } 950 STATUS current 951 DESCRIPTION 952 "A collection of objects to support basic management 953 of IPv4 and IPv6 Tunnels." 954 ::= { tunnelMIBGroups 2 } 956 END 958 5. IANA Considerations 960 This document introduces a new IANA-maintained textual convention 961 (TC) which is to be added to the IANAifType-MIB [IFTYPE]. The 962 initial version of this IANAtunnelType TC can be found in Appendix 963 A. The current version of the textual convention can be accessed 964 at http://www.iana.org/assignments/ianaiftype-mib 966 The assignment policy for IANAtunnelType values should always be 967 identical to the policy for assigning IANAifType values. 969 New types of tunnels over IPv4 or IPv6 should not be assigned 970 IANAifType values. Instead, they should be assigned 971 IANAtunnelType values and hence reuse the interface type 972 tunnel(131). (Note this restriction does not apply to "tunnels" 973 which are not over IPv4 or IPv6.) 975 Previously tunnel types which were not point-to-point tunnels were 976 problematic in that they could not be properly expressed in the 977 tunnel MIB, and hence were assigned IANAifType values. This 978 document now corrects this problem, and as a result, IANA should 979 deprecate the sixToFour(215) IANAifType value in favor of the 980 sixToFour(11) IANAtunnelType value. 982 Draft Inet Tunnel MIB October 2004 984 6. Security Considerations 986 There are a number of management objects defined in this MIB 987 module with a MAX-ACCESS clause of read-write and/or read-create. 988 Such objects may be considered sensitive or vulnerable in some 989 network environments. The support for SET operations in a non- 990 secure environment without proper protection can have a negative 991 effect on network operations. 993 Unauthorized write access to any of the writable objects could 994 cause unauthorized creation and/or manipulation of tunnels, 995 resulting in a denial of service, or redirection of packets to an 996 arbitrary destination. 998 Some of the readable objects in this MIB module (i.e., objects 999 with a MAX-ACCESS other than not-accessible) may be considered 1000 sensitive or vulnerable in some network environments. It is thus 1001 important to control even GET and/or NOTIFY access to these 1002 objects and possibly to even encrypt the values of these objects 1003 when sending them over the network via SNMP. 1005 Unauthorized read access to tunnelIfLocalInetAddress, 1006 tunnelIfRemoteInetAddress, tunnelIfLocalAddress, 1007 tunnelIfRemoteAddress, or any object in the tunnelConfigTable or 1008 tunnelInetConfigTable would reveal information about the tunnel 1009 topology. 1011 SNMP versions prior to SNMPv3 did not include adequate security. 1012 Even if the network itself is secure (for example by using IPSec), 1013 even then, there is no control as to who on the secure network is 1014 allowed to access and GET/SET (read/change/create/delete) the 1015 objects in this MIB module. 1017 It is RECOMMENDED that implementers consider the security features 1018 as provided by the SNMPv3 framework (see [RFC3410], section 8), 1019 including full support for the SNMPv3 cryptographic mechanisms 1020 (for authentication and privacy). 1022 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1023 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1024 enable cryptographic security. It is then a customer/operator 1025 responsibility to ensure that the SNMP entity giving access to an 1026 instance of this MIB module is properly configured to give access 1027 to the objects only to those principals (users) that have 1028 legitimate rights to indeed GET or SET (change/create/delete) 1029 Draft Inet Tunnel MIB October 2004 1031 them. 1033 7. Changes since RFC 2667 1035 IPv4-specific objects were deprecated, including 1036 tunnelIfLocalAddress, tunnelIfRemoteAddress, the 1037 tunnelConfigTable, and the tunnelMIBBasicGroup. 1039 Added IP version-agnostic objects that should be used instead, 1040 including tunnelIfAddressType, tunnelIfLocalInetAddress, 1041 tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the 1042 tunnelIMIBInetGroup. 1044 The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress 1045 objects are read-write, rather than read-only. 1047 Updated DESCRIPTION clauses of existing version-agnostic objects 1048 (e.g., tunnelIfTOS) that contained IPv4-specific text to cover 1049 IPv6 as well. 1051 Added tunnelIfFlowLabel for tunnels over IPv6. 1053 The encapsulation method was previously an INTEGER type, and is 1054 now an IANA-maintained textual convention. 1056 8. Acknowledgements 1058 This MIB module was updated based on feedback from the IETF's 1059 Interfaces MIB (IF-MIB), Point-to-Point Protocol Extensions 1060 (PPPEXT), and IPv6 Working Groups. Mike Heard and Ville Nuorvala 1061 also provided valuable MIB guidance on this version. 1063 9. Author's Address 1065 Dave Thaler 1066 Microsoft Corporation 1067 One Microsoft Way 1068 Redmond, WA 98052-6399 1070 Phone: +1 425 703 8835 1071 EMail: dthaler@microsoft.com 1072 Draft Inet Tunnel MIB October 2004 1074 10. Normative References 1076 [IFTYPE] Internet Assigned Numbers Authority, "IANAifType-MIB", 1077 http://www.iana.org/assignments/ianaiftype-mib 1079 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1080 IPv6 Specification", RFC 2473, December 1998. 1082 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1083 J., Rose, M. and S. Waldbusser, "Structure of 1084 Management Information Version 2 (SMIv2)", STD 58, RFC 1085 2578, April 1999. 1087 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1088 J., Rose, M. and S. Waldbusser, "Textual Conventions 1089 for SMIv2", STD 58, RFC 2579, April 1999. 1091 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1092 J., Rose, M. and S. Waldbusser, "Conformance 1093 Statements for SMIv2", STD 58, RFC 2580, April 1999. 1095 [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces 1096 Group MIB", RFC 2863, June 2000. 1098 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. 1099 Schoenwaelder, "Textual Conventions for Internet 1100 Network Addresses", RFC 3291, May 2002. 1102 [RFC3595] B. Wijnen, "Textual Conventions for IPv6 Flow Label", 1103 RFC 3595, September 2003. 1105 11. Informative References 1107 [RFC1234] D. Provan, "Tunneling IPX Traffic through IP 1108 Networks", RFC 1234, June 1991. 1110 [RFC1241] Woodburn, R. and D. Mills, "A Scheme for an Internet 1111 Encapsulation Protocol: Version 1", RFC 1241, July 1112 1991. 1114 [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, 1115 "Generic Routing Encapsulation (GRE)", RFC 1701, 1116 October 1994. 1118 Draft Inet Tunnel MIB October 2004 1120 [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, 1121 "Generic Routing Encapsulation over IPv4 networks", 1122 RFC 1702, October 1994. 1124 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1125 October 1996. 1127 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 1128 2004, October 1996. 1130 [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - 1131 ATMP", RFC 2107, February 1997. 1133 [RFC2341] Valencia, A., Littlewood, M. and T. Kolar. "Cisco 1134 Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1135 1998. 1137 [RFC2401] R. Atkinson, "Security architecture for the internet 1138 protocol", RFC 2401, November 1998. 1140 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black. 1141 "Definition of the Differentiated Services Field (DS 1142 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1143 December 1998. 1145 [RFC2637] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little, 1146 W. and G. Zorn, "Point-to-Point Tunneling Protocol", 1147 RFC 2637, July 1999. 1149 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., 1150 Zorn, G. and B. Palter, "Layer Two Tunneling Protocol 1151 "L2TP"", RFC 2661, August 1999. 1153 [RFC2893] Gilligan, R. and E. Nordmark. "Transition Mechanisms 1154 for IPv6 Hosts and Routers", RFC 2893, August 2000. 1156 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1157 "Introduction and Applicability Statements for 1158 Internet-Standard Management Framework", RFC 3410, 1159 December 2002. 1161 Draft Inet Tunnel MIB October 2004 1163 12. Appendix A: IANA Tunnel Type TC 1165 This appendix defines the initial content of the IANAtunnelType 1166 textual convention which should appear in the IANAifType-MIB. 1168 IANAtunnelType ::= TEXTUAL-CONVENTION 1169 STATUS current 1170 DESCRIPTION 1171 "The encapsulation method used by a tunnel. The value 1172 direct indicates that a packet is encapsulated 1173 directly within a normal IP header, with no 1174 intermediate header, and unicast to the remote tunnel 1175 endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC 1176 1933 IPv6-in-IPv4 tunnel). The value minimal indicates 1177 that a Minimal Forwarding Header (RFC 2004) is 1178 inserted between the outer header and the payload 1179 packet. The value UDP indicates that the payload 1180 packet is encapsulated within a normal UDP packet 1181 (e.g., RFC 1234). 1183 The values sixToFour, sixOverFour, and isatap 1184 indicates that an IPv6 packet is encapsulated directly 1185 within an IPv4 header, with no intermediate header, 1186 and unicast to the destination determined by the 6to4, 1187 6over4, or ISATAP protocol. 1189 The remaining protocol-specific values indicate that a 1190 header of the protocol of that name is inserted 1191 between the outer header and the payload header. 1193 The assignment policy for IANAtunnelType values is 1194 identical to the policy for assigning IANAifType 1195 values." 1196 SYNTAX INTEGER { 1197 other(1), -- none of the following 1198 direct(2), -- no intermediate header 1199 gre(3), -- GRE encapsulation 1200 minimal(4), -- Minimal encapsulation 1201 l2tp(5), -- L2TP encapsulation 1202 pptp(6), -- PPTP encapsulation 1203 l2f(7), -- L2F encapsulation 1204 udp(8), -- UDP encapsulation 1205 atmp(9), -- ATMP encapsulation 1206 msdp(10), -- MSDP encapsulation 1207 sixToFour(11), -- 6to4 encapsulation 1209 Draft Inet Tunnel MIB October 2004 1211 sixOverFour(12), -- 6over4 encapsulation 1212 isatap(13), -- ISATAP encapsulation 1213 teredo(14) -- Teredo encapsulation 1214 } 1216 13. Full Copyright Statement 1218 Copyright (C) The Internet Society (2004). This document is 1219 subject to the rights, licenses and restrictions contained in BCP 1220 78, and except as set forth therein, the authors retain all their 1221 rights. 1223 This document and the information contained herein are provided on 1224 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1225 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1226 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1227 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1228 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1229 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1230 PARTICULAR PURPOSE. 1232 14. Intellectual Property 1234 The IETF takes no position regarding the validity or scope of any 1235 intellectual property or other rights that might be claimed to 1236 pertain to the implementation or use of the technology described 1237 in this document or the extent to which any license under such 1238 rights might or might not be available; neither does it represent 1239 that it has made any effort to identify any such rights. 1240 Information on the IETF's procedures with respect to rights in 1241 standards-track and standards-related documentation can be found 1242 in BCP-11. Copies of claims of rights made available for 1243 publication and any assurances of licenses to be made available, 1244 or the result of an attempt made to obtain a general license or 1245 permission for the use of such proprietary rights by implementors 1246 or users of this specification can be obtained from the IETF 1247 Secretariat. 1249 The IETF invites any interested party to bring to its attention 1250 any copyrights, patents or patent applications, or other 1251 proprietary rights which may cover technology that may be required 1252 to practice this standard. Please address the information to the 1253 IETF Executive Director.