--- 1/draft-ietf-ipv6-inet-tunnel-mib-00.txt 2006-02-05 00:02:33.000000000 +0100 +++ 2/draft-ietf-ipv6-inet-tunnel-mib-01.txt 2006-02-05 00:02:33.000000000 +0100 @@ -1,109 +1,108 @@ - Network Working Group D. Thaler INTERNET-DRAFT Microsoft -Expires July 2004 January 2004 +Expires January 2005 July 2004 IP Tunnel MIB - + Status of this Memo -This document is an Internet-Draft and is in full conformance with -all provisions of Section 10 of RFC2026. +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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other -documents at any time. It is inappropriate to use Internet- -Drafts as reference material or to cite them other than as "work -in progress." +documents at any time. It is inappropriate to use Internet-Drafts +as reference material or to cite them other than a "work in +progress." The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt +http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. +http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. -Abstract +Draft Inet Tunnel MIB July 2004 -Draft Inet Tunnel MIB January 2004 +Abstract This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIBs. 1. Introduction Over the past several years, there have been a number of "tunneling" protocols specified by the IETF (see [RFC1241] for an early discussion of the model and examples). This document describes a Management Information Base (MIB) used for managing -tunnels of any type over IPv4 networks, including GRE +tunnels of any type over IPv4 and IPv6 networks, including GRE [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal Encapsulation [RFC2004], L2TP [RFC2661], PPTP [RFC2637], L2F [RFC2341], UDP (e.g., [RFC1234]), ATMP [RFC2107], and IPv6-in-IPv4 [RFC2893] -tunnels. +tunnels, among others. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects (e.g., IPSEC [RFC2401]), and traffic -conditioner [RFC2474] objects. Finally, this MIB does not support -tunnels over non- IPv4 networks (including IPv6 networks). -Management of such tunnels may be supported by other MIBs. +conditioner [RFC2474] objects. 2. The Internet-Standard Management Framework - For a detailed overview of the documents that describe the - current Internet-Standard Management Framework, please refer to - section 7 of RFC 3410 [RFC3410]. +For a detailed overview of the documents that describe the current +Internet-Standard Management Framework, please refer to section 7 +of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are - generally accessed through the Simple Network Management - Protocol (SNMP). Objects in the MIB are defined using the - mechanisms defined in the Structure of Management Information - (SMI). This memo specifies a MIB module that is compliant to - the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], - STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. +generally accessed through the Simple Network Management Protocol +(SNMP). Objects in the MIB are defined using the mechanisms +defined in the Structure of Management Information (SMI). This +memo specifies a MIB module that is compliant to the SMIv2, which +is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 +[RFC2579] and STD 58, RFC 2580 [RFC2580]. -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 3. Overview This MIB module contains two current tables and one deprecated table. The current tables are: o the Tunnel Interface Table, containing information on the tunnels known to a router; and o the Tunnel Inet Config Table, which can be used for dynamic creation of tunnels, and also provides a mapping from endpoint addresses to the current interface index value. - The version of this MIB that appeared in RFC 2667 contained - the Tunnel Config Table, which mapped IPv4 endpoint addresses - to interface indexes. It is now deprecated in favor of the - Tunnel Inet Config Table. +The version of this MIB that appeared in RFC 2667 contained the +Tunnel Config Table, which mapped IPv4 endpoint addresses to +interface indexes. It is now deprecated in favor of the Tunnel +Inet Config Table. 3.1. Relationship to the Interfaces MIB This section clarifies the relationship of this MIB to the Interfaces MIB [RFC2863]. Several areas of correlation are addressed in the following subsections. The implementor is referred to the Interfaces MIB document in order to understand the general intent of these areas. 3.1.1. Layering Model @@ -118,21 +117,21 @@ | | | | | | +--+ +---+ +--+ +---+ | | |IP-in-IP| | GRE | | | | tunnel | | tunnel | | | +--+ +---+ +--+ +---+ | | | | | | | | <== attachment to underlying +--+ +---------+ +----------+ +--+ interfaces, to be provided | Physical interface | by ifStack table -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 +--------------------------------+ 3.1.2. ifRcvAddressTable The ifRcvAddressTable usage can be defined in the MIBs defining the encapsulation below the network layer, and holds the local IP addresses on which decapsulation will occur. For example, if IP- in-IP encapsulation is being used, the ifRcvAddressTable can be defined by IP- in-IP. If it is not specified, the default is that @@ -161,21 +160,21 @@ creation directly in the Tunnel Interface Table, indexed by ifIndex, would complicate row creation and/or cause interoperability problems (if each agent had special restrictions on ifIndex). Instead, a separate table is used which is indexed only by objects over which the manager has control. Namely, these are the addresses of the tunnel endpoints and the encapsulation protocol. Finally, an additional manager- chosen ID is used in the index to support protocols such as L2F which allow multiple tunnels between the same endpoints. -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 3.1.4. ifEntry IfEntries are defined in the MIBs defining the encapsulation below the network layer. For example, if IP-in-IP encapsulation [20] is being used, the ifEntry is defined by IP-in-IP. The ifType of a tunnel should be set to "tunnel" (131). An entry in the IP Tunnel MIB will exist for every ifEntry with this ifType. An implementation of the IP Tunnel MIB may allow @@ -202,27 +201,27 @@ TUNNEL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Integer32, IpAddress FROM SNMPv2-SMI RowStatus, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddressType, InetAddress FROM INET-ADDRESS-MIB IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB ifIndex, InterfaceIndexOrZero FROM IF-MIB - IANAtunnelType FROM IANA-TUNNELTYPE-MIB; + IANAtunnelType FROM IANAifType-MIB; tunnelMIB MODULE-IDENTITY LAST-UPDATED "200401191200Z" -- January 19, 2003 ORGANIZATION "IETF Interfaces MIB Working Group" -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 CONTACT-INFO " Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: dthaler@microsoft.com" DESCRIPTION "The MIB module for management of IP Tunnels, independent of the specific encapsulation scheme in @@ -256,21 +255,21 @@ STATUS current DESCRIPTION "The (conceptual) table containing information on configured tunnels." ::= { tunnel 1 } tunnelIfEntry OBJECT-TYPE SYNTAX TunnelIfEntry MAX-ACCESS not-accessible -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular configured tunnel." INDEX { ifIndex } ::= { tunnelIfTable 1 } TunnelIfEntry ::= SEQUENCE { tunnelIfLocalAddress IpAddress, -- deprecated @@ -303,21 +302,21 @@ STATUS deprecated DESCRIPTION "The address of the remote endpoint of the tunnel (i.e., the destination address used in the outer IP header), or 0.0.0.0 if unknown, or an IPv6 address, or the tunnel is not a point-to-point link (e.g., if it is a 6to4 tunnel). This object is deprecated in favor of tunnelIfRemoteInetAddress." ::= { tunnelIfEntry 2 } -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 tunnelIfEncapsMethod OBJECT-TYPE SYNTAX IANAtunnelType MAX-ACCESS read-only STATUS current DESCRIPTION "The encapsulation method used by the tunnel." ::= { tunnelIfEntry 3 } tunnelIfHopLimit OBJECT-TYPE @@ -351,21 +350,21 @@ SYNTAX Integer32 (-2..63) MAX-ACCESS read-write STATUS current DESCRIPTION "The method used to set the high 6 bits of the IPv4 TOS or IPv6 Traffic Class in the outer IP header. A value of -1 indicates that the bits are copied from the payload's header. A value of -2 indicates that a traffic conditioner is invoked and more information -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 may be available in a traffic conditioner MIB. A value between 0 and 63 inclusive indicates that the bit field is set to the indicated value." ::= { tunnelIfEntry 6 } tunnelIfFlowLabel OBJECT-TYPE SYNTAX IPv6FlowLabelOrAny MAX-ACCESS read-write STATUS current @@ -399,21 +398,21 @@ (i.e., the source address used in the outer IP header). If the address is unknown, the value is 0.0.0.0 for IPv4 or :: for IPv6." ::= { tunnelIfEntry 9 } tunnelIfRemoteInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 DESCRIPTION "The address of the remote endpoint of the tunnel (i.e., the destination address used in the outer IP header). If the address is unknown or the tunnel is not a point-to-point link (e.g., if it is a 6to4 tunnel), the value is 0.0.0.0 for tunnels over IPv4 or :: for tunnels over IPv6." ::= { tunnelIfEntry 10 } @@ -447,21 +446,21 @@ ::= { tunnelConfigTable 1 } TunnelConfigEntry ::= SEQUENCE { tunnelConfigLocalAddress IpAddress, tunnelConfigRemoteAddress IpAddress, tunnelConfigEncapsMethod IANAtunnelType, tunnelConfigID Integer32, tunnelConfigIfIndex InterfaceIndexOrZero, tunnelConfigStatus RowStatus -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 } tunnelConfigLocalAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The address of the local endpoint of the tunnel, or 0.0.0.0 if the device is free to choose any of its @@ -494,21 +493,21 @@ same endpoints. If the encapsulation protocol only allows one tunnel per set of endpoint addresses (such as for GRE or IP-in-IP), the value of this object is 1. For encapsulation methods (such as L2F) which allow multiple parallel tunnels, the manager is responsible for choosing any ID which does not conflict with an existing row, such as choosing a random number." ::= { tunnelConfigEntry 4 } -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 tunnelConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS deprecated DESCRIPTION "If the value of tunnelConfigStatus for this row is active, then this object contains the value of ifIndex corresponding to the tunnel interface. A value of 0 is not legal in the active state, and means that the @@ -542,21 +541,21 @@ inconsistentValue is returned in response to the set operation, the management station should simply select a new pseudo-random number and retry the operation. Creating a row in this table will cause an interface index to be assigned by the agent in an implementation-dependent manner, and corresponding rows will be instantiated in the ifTable and the tunnelIfTable. The status of this row will become -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 active as soon as the agent assigns the interface index, regardless of whether the interface is operationally up. Deleting a row in this table will likewise delete the corresponding row in the ifTable and in the tunnelIfTable." ::= { tunnelConfigEntry 6 } @@ -590,21 +589,21 @@ cause the limit to be exceeded." INDEX { tunnelInetConfigAddressType, tunnelInetConfigLocalAddress, tunnelInetConfigRemoteAddress, tunnelInetConfigEncapsMethod, tunnelInetConfigID } ::= { tunnelInetConfigTable 1 } TunnelInetConfigEntry ::= SEQUENCE { -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 tunnelInetConfigAddressType InetAddressType, tunnelInetConfigLocalAddress InetAddress, tunnelInetConfigRemoteAddress InetAddress, tunnelInetConfigEncapsMethod IANAtunnelType, tunnelInetConfigID Integer32, tunnelInetConfigIfIndex InterfaceIndexOrZero, tunnelInetConfigStatus RowStatus, tunnelInetConfigStorageType StorageType } @@ -617,41 +616,42 @@ "The address type over which the tunnel encapsulates packets." ::= { tunnelInetConfigEntry 1 } tunnelInetConfigLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the local endpoint of the tunnel, or - 0.0.0.0 if the device is free to choose any of its - addresses at tunnel establishment time." + 0.0.0.0 (for IPv4) or :: (for IPv6) if the device is + free to choose any of its addresses at tunnel + establishment time." ::= { tunnelInetConfigEntry 2 } tunnelInetConfigRemoteAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the remote endpoint of the tunnel." ::= { tunnelInetConfigEntry 3 } tunnelInetConfigEncapsMethod OBJECT-TYPE SYNTAX IANAtunnelType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The encapsulation method used by the tunnel." ::= { tunnelInetConfigEntry 4 } -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 tunnelInetConfigID OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier used to distinguish between multiple tunnels of the same encapsulation method, with the same endpoints. If the encapsulation protocol only allows one tunnel per set of endpoint addresses (such @@ -685,21 +685,21 @@ agent need not support setting this object to createAndWait or notInService since there are no other writable objects in this table, and writable objects in rows of corresponding tables such as the tunnelIfTable may be modified while this row is active. To create a row in this table for an encapsulation method which does not support multiple parallel -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 tunnels with the same endpoints, the management station should simply use a tunnelInetConfigID of 1, and set tunnelInetConfigStatus to createAndGo. For encapsulation methods such as L2F which allow multiple parallel tunnels, the management station may select a pseudo-random number to use as the tunnelInetConfigID and set tunnelInetConfigStatus to createAndGo. In the event that this ID is already in use and an inconsistentValue is returned in response to the set @@ -732,21 +732,21 @@ -- conformance information tunnelMIBConformance OBJECT IDENTIFIER ::= { tunnelMIB 2 } tunnelMIBCompliances OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 } tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 } -- compliance statements -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 tunnelMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The (deprecated) IPv4-only compliance statement for the IP Tunnel MIB." MODULE -- this module MANDATORY-GROUPS { tunnelMIBGroup } OBJECT tunnelIfHopLimit @@ -780,21 +780,21 @@ and/or IPv6 addresses. An implementation only needs to support the addresses it actually supports on the device." OBJECT tunnelInetConfigStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 required." ::= { tunnelMIBCompliances 2 } tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The read-only compliance statement for the IP Tunnel MIB." MODULE -- this module @@ -828,21 +828,21 @@ device." OBJECT tunnelIfLocalInetAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tunnelIfRemoteInetAddress MIN-ACCESS read-only -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 DESCRIPTION "Write access is not required." OBJECT tunnelInetConfigStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." @@ -872,21 +872,21 @@ tunnelIfSecurity, tunnelInetConfigIfIndex, tunnelInetConfigStatus, tunnelInetConfigStorageType } STATUS current DESCRIPTION "A collection of objects to support basic management of IPv4 and IPv6 Tunnels." ::= { tunnelMIBGroups 2 } END -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 5. IANA Considerations This document introduces a new IANA-maintained textual convention (TC) which is to be added to the IANAifType-MIB. The initial version of this IANAtunnelType TC can be found in Appendix A. The current version of the textual convention can be accessed at http://www.iana.org/assignments/ianaiftype-mib The policy for assigning new IANAtunnelType values is First Come @@ -919,21 +919,21 @@ Unauthorized write access to any of the writable objects could cause unauthorized creation and/or manipulation of tunnels, resulting in a denial of service, or redirection of packets to an arbitrary destination. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Unauthorized read access to tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, tunnelIfLocalAddress, tunnelIfRemoteAddress, or any object in the tunnelConfigTable or tunnelInetConfigTable would reveal information about the tunnel topology. @@ -964,21 +964,21 @@ Interfaces MIB (IF-MIB) and Point-to-Point Protocol Extensions (PPPEXT) Working Groups. 8. Authors' Addresses Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com 9. Normative References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. @@ -1010,21 +1010,21 @@ Encapsulation Protocol: Version 1", RFC 1241, July 1991. [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation over IPv4 networks", -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 RFC 1702, October 1994. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - @@ -1056,21 +1056,21 @@ [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 11. Appendix A: IANA Tunnel Type TC This appendix defines the initial content of the IANAtunnelType textual convention which should appear in the IANAifType-MIB. -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 IANAtunnelType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The encapsulation method used by a tunnel. The value direct indicates that a packet is encapsulated directly within a normal IP header, with no intermediate header, and unicast to the remote tunnel endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC 1933 IPv6-in-IPv4 tunnel). The value minimal indicates @@ -1099,64 +1099,50 @@ l2f(7), -- L2F encapsulation udp(8), -- UDP encapsulation atmp(9), -- ATMP encapsulation msdp(10), -- MSDP encapsulation sixToFour(11), -- 6to4 encapsulation sixOverFour(12), -- 6over4 encapsulation isatap(13), -- ISATAP encapsulation teredo(14) -- Teredo encapsulation } -Draft Inet Tunnel MIB January 2004 +Draft Inet Tunnel MIB July 2004 12. Full Copyright Statement -Copyright (C) The Internet Society (2004). All Rights Reserved. - -This document and translations of it may be copied and furnished -to others, and derivative works that comment on or otherwise -explain it or assist in its implmentation may be prepared, copied, -published and distributed, in whole or in part, without -restriction of any kind, provided that the above copyright notice -and this paragraph are included on all such copies and derivative -works. However, this document itself may not be modified in any -way, such as by removing the copyright notice or references to the -Internet Society or other Internet organizations, except as needed -for the purpose of developing Internet standards in which case the -procedures for copyrights defined in the Internet Standards -process must be followed, or as required to translate it into -languages other than English. - -The limited permissions granted above are perpetual and will not -be revoked by the Internet Society or its successors or assigns. +Copyright (C) The Internet Society (2004). This document is +subject to the rights, licenses and restrictions contained in BCP +78, and except as set forth therein, the authors retain all their +rights. -This document and the information contained herein is provided on -an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET -ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF -THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED -WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. +This document and the information contained herein are provided on +an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE +REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND +THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT +THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR +ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A +PARTICULAR PURPOSE. 13. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. -Draft Inet Tunnel MIB January 2004 - The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the -IETF Executive Director." +IETF Executive Director.