doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc2667.txt b/doc/rfc/rfc2667.txt
new file mode 100644
index 0000000..f625925
--- /dev/null
+++ b/doc/rfc/rfc2667.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          D. Thaler
+Request for Comments: 2667                                     Microsoft
+Category: Standards Track                                    August 1999
+
+
+                             IP Tunnel MIB
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1.  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 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-IPv4 networks (including IPv6 networks).
+   Management of such tunnels may be supported by other MIBs.
+
+Table of Contents
+
+    1 Abstract ...................................................... 1
+    2 Introduction .................................................. 2
+    3 The SNMP Network Management Framework ......................... 2
+    4 Overview ...................................................... 3
+    4.1 Relationship to the Interfaces MIB .......................... 3
+    4.1.1 Layering Model ............................................ 3
+    4.1.2 ifRcvAddressTable ......................................... 4
+    4.1.3 ifEntry ................................................... 4
+    5 Definitions ................................................... 4
+    6 Security Considerations ...................................... 12
+    7 Acknowledgements ............................................. 12
+    8 Author's Address ............................................. 12
+    9 References ................................................... 13
+   10 Intellectual Property Notice ................................. 15
+   11 Full Copyright Statement ..................................... 16
+
+
+
+
+Thaler                      Standards Track                     [Page 1]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+2.  Introduction
+
+   Over the past several years, there have been a number of "tunneling"
+   protocols specified by the IETF (see [28] 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 [16,17], IP-in-IP [18], Minimal
+   Encapsulation [19], L2TP [20], PPTP [21], L2F [25], UDP (e.g., [26]),
+   ATMP [22], and IPv6-in-IPv4 [27] tunnels.
+
+   Extension MIBs may be designed for managing protocol-specific
+   objects.  Likewise, extension MIBs may be designed for managing
+   security-specific objects (e.g., IPSEC [24]), and traffic conditioner
+   [29] 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.
+
+3.  The SNMP Network Management Framework
+
+   The SNMP Management Framework presently consists of five major
+   components:
+
+   o    An overall architecture, described in RFC 2571 [1].
+
+   o    Mechanisms for describing and naming objects and events for the
+        purpose of management. The first version of this Structure of
+        Management Information (SMI) is called SMIv1 and described in
+        STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
+        second version, called SMIv2, is described in STD 58, RFC 2578
+        [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].
+
+   o    Message protocols for transferring management information. The
+        first version of the SNMP message protocol is called SNMPv1 and
+        described in STD 15, RFC 1157 [8]. A second version of the SNMP
+        message protocol, which is not an Internet standards track
+        protocol, is called SNMPv2c and described in RFC 1901 [9] and
+        RFC 1906 [10].  The third version of the message protocol is
+        called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and
+        RFC 2574 [12].
+
+   o    Protocol operations for accessing management information. The
+        first set of protocol operations and associated PDU formats is
+        described in STD 15, RFC 1157 [8]. A second set of protocol
+        operations and associated PDU formats is described in RFC 1905
+        [13].
+
+
+
+
+
+
+Thaler                      Standards Track                     [Page 2]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+   o    A set of fundamental applications described in RFC 2573 [14] and
+        the view-based access control mechanism described in RFC 2575
+        [15].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the mechanisms defined in the SMI.
+
+   This memo specifies a MIB module that is compliant to the SMIv2. A
+   MIB conforming to the SMIv1 can be produced through the appropriate
+   translations. The resulting translated MIB must be semantically
+   equivalent, except where objects or events are omitted because no
+   translation is possible (use of Counter64). Some machine readable
+   information in SMIv2 will be converted into textual descriptions in
+   SMIv1 during the translation process. However, this loss of machine
+   readable information is not considered to change the semantics of the
+   MIB.
+
+4.  Overview
+
+   This MIB module contains two tables:
+
+   o    the Tunnel Interface Table, containing information on the
+        tunnels known to a router; and
+
+   o    the Tunnel 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.
+
+4.1.  Relationship to the Interfaces MIB
+
+   This section clarifies the relationship of this MIB to the Interfaces
+   MIB [23].  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.
+
+4.1.1.  Layering Model
+
+   Each logical interface (physical or virtual) has an ifEntry in the
+   Interfaces MIB [23].  Tunnels are handled by creating a logical
+   interface (ifEntry) for each tunnel. These are then correlated, using
+   the ifStack table of the Interfaces MIB, to those interfaces on which
+   the local IPv4 addresses of the tunnels are configured.  The basic
+   model, therefore, looks something like this (for example):
+
+
+
+
+
+
+Thaler                      Standards Track                     [Page 3]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+         | |         | |          | |
+      +--+ +---+  +--+ +---+      | |
+      |IP-in-IP|  |  GRE   |      | |
+      | tunnel |  | tunnel |      | |
+      +--+ +---+  +--+ +---+      | |
+         | |         | |          | |    <== attachment to underlying
+      +--+ +---------+ +----------+ +--+     interfaces, to be provided
+      |       Physical interface       |     by ifStack table
+      +--------------------------------+
+
+4.1.2.  ifRcvAddressTable
+
+   The ifRcvAddressTable usage is defined in the MIBs defining the
+   encapsulation below the network layer.  For example, if IP-in-IP
+   encapsulation is being used, the ifRcvAddressTable is defined by IP-
+   in-IP.
+
+4.1.3.  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 ifEntries to be created
+   via the tunnelConfigTable.  Creating a tunnel will also add an entry
+   in the ifTable and in the tunnelIfTable, and deleting a tunnel will
+   likewise delete the entry in the ifTable and the tunnelIfTable.
+
+   The use of two different tables in this MIB was an important design
+   decision.  Traditionally, ifIndex values are chosen by agents, and
+   are permitted to change across restarts.  Allowing row 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.
+
+
+
+
+
+
+
+
+
+
+Thaler                      Standards Track                     [Page 4]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+5.  Definitions
+
+TUNNEL-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+    MODULE-IDENTITY, OBJECT-TYPE, transmission,
+    Integer32, IpAddress             FROM SNMPv2-SMI
+    RowStatus                        FROM SNMPv2-TC
+    MODULE-COMPLIANCE, OBJECT-GROUP  FROM SNMPv2-CONF
+    ifIndex, InterfaceIndexOrZero    FROM IF-MIB;
+
+tunnelMIB MODULE-IDENTITY
+    LAST-UPDATED "9908241200Z" -- August 24, 1999
+    ORGANIZATION "IETF Interfaces MIB Working Group"
+    CONTACT-INFO
+            " Dave Thaler
+              Microsoft Corporation
+              One Microsoft Way
+              Redmond, WA  98052-6399
+              EMail: dthaler@dthaler.microsoft.com"
+    DESCRIPTION
+            "The MIB module for management of IP Tunnels, independent of
+            the specific encapsulation scheme in use."
+    REVISION     "9908241200Z" -- August 24, 1999
+    DESCRIPTION
+            "Initial version, published as RFC 2667."
+    ::= { transmission 131 }
+
+tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 }
+
+tunnel      OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 }
+
+-- the IP Tunnel MIB-Group
+--
+-- a collection of objects providing information about
+-- IP Tunnels
+
+tunnelIfTable OBJECT-TYPE
+    SYNTAX     SEQUENCE OF TunnelIfEntry
+    MAX-ACCESS not-accessible
+    STATUS     current
+    DESCRIPTION
+            "The (conceptual) table containing information on configured
+            tunnels."
+    ::= { tunnel 1 }
+
+tunnelIfEntry OBJECT-TYPE
+    SYNTAX     TunnelIfEntry
+
+
+
+Thaler                      Standards Track                     [Page 5]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+    MAX-ACCESS not-accessible
+    STATUS     current
+    DESCRIPTION
+            "An entry (conceptual row) containing the information on a
+            particular configured tunnel."
+    INDEX      { ifIndex }
+    ::= { tunnelIfTable 1 }
+
+TunnelIfEntry ::= SEQUENCE {
+    tunnelIfLocalAddress            IpAddress,
+    tunnelIfRemoteAddress           IpAddress,
+    tunnelIfEncapsMethod            INTEGER,
+    tunnelIfHopLimit                Integer32,
+    tunnelIfSecurity                INTEGER,
+    tunnelIfTOS                     Integer32
+}
+
+tunnelIfLocalAddress OBJECT-TYPE
+    SYNTAX     IpAddress
+    MAX-ACCESS read-only
+    STATUS     current
+    DESCRIPTION
+            "The address of the local endpoint of the tunnel (i.e., the
+            source address used in the outer IP header), or 0.0.0.0 if
+            unknown."
+    ::= { tunnelIfEntry 1 }
+
+tunnelIfRemoteAddress OBJECT-TYPE
+    SYNTAX     IpAddress
+    MAX-ACCESS read-only
+    STATUS     current
+    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."
+    ::= { tunnelIfEntry 2 }
+
+tunnelIfEncapsMethod OBJECT-TYPE
+    SYNTAX     INTEGER {
+                   other(1),   -- none of the following
+                   direct(2),  -- no intermediate header
+                   gre(3),     -- GRE encapsulation
+                   minimal(4), -- Minimal encapsulation
+                   l2tp(5),    -- L2TP encapsulation
+                   pptp(6),    -- PPTP encapsulation
+                   l2f(7),     -- L2F encapsulation
+                   udp(8),     -- UDP encapsulation
+                   atmp(9)     -- ATMP encapsulation
+
+
+
+Thaler                      Standards Track                     [Page 6]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+               }
+    MAX-ACCESS read-only
+    STATUS     current
+    DESCRIPTION
+            "The encapsulation method used by the tunnel. The value
+            direct indicates that the packet is encapsulated directly
+            within a normal IPv4 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 that a Minimal Forwarding Header
+            (RFC 2004) is inserted between the outer header and the
+            payload packet. The value UDP indicates that the payload
+            packet is encapsulated within a normal UDP packet (e.g., RFC
+            1234).  The remaining protocol-specific values indicate that
+            a header of the protocol of that name is inserted between
+            the outer header and the payload header."
+    ::= { tunnelIfEntry 3 }
+
+tunnelIfHopLimit OBJECT-TYPE
+    SYNTAX     Integer32 (0..255)
+    MAX-ACCESS read-write
+    STATUS     current
+    DESCRIPTION
+            "The TTL to use in the outer IP header. A value of 0
+            indicates that the value is copied from the payload's
+            header."
+    ::= { tunnelIfEntry 4 }
+
+tunnelIfSecurity OBJECT-TYPE
+    SYNTAX     INTEGER {
+                   none(1),   -- no security
+                   ipsec(2),  -- IPSEC security
+                   other(3)
+               }
+    MAX-ACCESS read-only
+    STATUS     current
+    DESCRIPTION
+            "The method used by the tunnel to secure the outer IP
+            header.  The value ipsec indicates that IPsec is used
+            between the tunnel endpoints for authentication or
+            encryption or both.  More specific security-related
+            information may be available in a MIB for the security
+            protocol in use."
+    ::= { tunnelIfEntry 5 }
+
+tunnelIfTOS OBJECT-TYPE
+    SYNTAX     Integer32 (-2..63)
+    MAX-ACCESS read-write
+
+
+
+Thaler                      Standards Track                     [Page 7]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+    STATUS     current
+    DESCRIPTION
+            "The method used to set the high 6 bits of the TOS 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
+            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 }
+
+tunnelConfigTable OBJECT-TYPE
+    SYNTAX     SEQUENCE OF TunnelConfigEntry
+    MAX-ACCESS not-accessible
+    STATUS     current
+    DESCRIPTION
+            "The (conceptual) table containing information on configured
+            tunnels.  This table can be used to map a set of tunnel
+            endpoints to the associated ifIndex value.  It can also be
+            used for row creation.  Note that every row in the
+            tunnelIfTable with a fixed destination address should have a
+            corresponding row in the tunnelConfigTable, regardless of
+            whether it was created via SNMP."
+    ::= { tunnel 2 }
+
+tunnelConfigEntry OBJECT-TYPE
+    SYNTAX     TunnelConfigEntry
+    MAX-ACCESS not-accessible
+    STATUS     current
+    DESCRIPTION
+            "An entry (conceptual row) containing the information on a
+            particular configured tunnel."
+    INDEX      { tunnelConfigLocalAddress,
+                 tunnelConfigRemoteAddress,
+                 tunnelConfigEncapsMethod,
+                 tunnelConfigID }
+    ::= { tunnelConfigTable 1 }
+
+TunnelConfigEntry ::= SEQUENCE {
+    tunnelConfigLocalAddress            IpAddress,
+    tunnelConfigRemoteAddress           IpAddress,
+    tunnelConfigEncapsMethod            INTEGER,
+    tunnelConfigID                      Integer32,
+    tunnelConfigIfIndex                 InterfaceIndexOrZero,
+    tunnelConfigStatus                  RowStatus
+}
+
+tunnelConfigLocalAddress OBJECT-TYPE
+
+
+
+Thaler                      Standards Track                     [Page 8]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+    SYNTAX     IpAddress
+    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."
+    ::= { tunnelConfigEntry 1 }
+
+tunnelConfigRemoteAddress OBJECT-TYPE
+    SYNTAX     IpAddress
+    MAX-ACCESS not-accessible
+    STATUS     current
+    DESCRIPTION
+            "The address of the remote endpoint of the tunnel."
+    ::= { tunnelConfigEntry 2 }
+
+tunnelConfigEncapsMethod OBJECT-TYPE
+    SYNTAX     INTEGER {
+                   other(1),   -- none of the following
+                   direct(2),  -- no intermediate header
+                   gre(3),     -- GRE encapsulation
+                   minimal(4), -- Minimal encapsulation
+                   l2tp(5),    -- L2TP encapsulation
+                   pptp(6),    -- PPTP encapsulation
+                   l2f(7),     -- L2F encapsulation
+                   udp(8),     -- UDP encapsulation
+                   atmp(9)
+               }
+    MAX-ACCESS not-accessible
+    STATUS     current
+    DESCRIPTION
+            "The encapsulation method used by the tunnel."
+    ::= { tunnelConfigEntry 3 }
+
+tunnelConfigID 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 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."
+
+
+
+Thaler                      Standards Track                     [Page 9]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+    ::= { tunnelConfigEntry 4 }
+
+tunnelConfigIfIndex OBJECT-TYPE
+    SYNTAX     InterfaceIndexOrZero
+    MAX-ACCESS read-only
+    STATUS     current
+    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 interface index has not yet
+            been assigned."
+    ::= { tunnelConfigEntry 5 }
+
+tunnelConfigStatus OBJECT-TYPE
+    SYNTAX     RowStatus
+    MAX-ACCESS read-create
+    STATUS     current
+    DESCRIPTION
+            "The status of this row, by which new entries may be
+            created, or old entries deleted from this table. The 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 tunnels with the
+            same endpoints, the management station should simply use a
+            tunnelConfigID of 1, and set tunnelConfigStatus 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 tunnelConfigID
+            and set tunnelConfigStatus to createAndGo.  In the event
+            that this ID is already in use and an 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 active as soon as the agent assigns the interface
+            index, regardless of whether the interface is operationally
+            up.
+
+
+
+
+Thaler                      Standards Track                    [Page 10]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+            Deleting a row in this table will likewise delete the
+            corresponding row in the ifTable and in the tunnelIfTable."
+    ::= { tunnelConfigEntry 6 }
+
+-- conformance information
+
+tunnelMIBConformance
+                  OBJECT IDENTIFIER ::= { tunnelMIB 2 }
+tunnelMIBCompliances
+                  OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 }
+tunnelMIBGroups  OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 }
+
+-- compliance statements
+
+tunnelMIBCompliance MODULE-COMPLIANCE
+    STATUS  current
+    DESCRIPTION
+            "The compliance statement for the IP Tunnel MIB."
+    MODULE  -- this module
+    MANDATORY-GROUPS { tunnelMIBBasicGroup }
+
+        OBJECT      tunnelIfHopLimit
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+
+        OBJECT      tunnelIfTOS
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+
+        OBJECT      tunnelConfigStatus
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is not required."
+   ::= { tunnelMIBCompliances 1 }
+
+-- units of conformance
+
+tunnelMIBBasicGroup OBJECT-GROUP
+    OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress,
+       tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS,
+       tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects to support basic management of IP
+            Tunnels."
+    ::= { tunnelMIBGroups 1 }
+
+
+
+Thaler                      Standards Track                    [Page 11]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+END
+
+6.  Security Considerations
+
+   This MIB contains readable objects whose values provide information
+   related to IP tunnel interfaces.  There are also a number of objects
+   that have a MAX-ACCESS clause of read-write and/or read-create, such
+   as those which allow an administrator to dynamically configure
+   tunnels.
+
+   While unauthorized access to the readable objects is relatively
+   innocuous, unauthorized access to the write-able objects could cause
+   a denial of service, or could cause unauthorized creation and/or
+   manipulation of tunnels. Hence, the support for SET operations in a
+   non-secure environment without proper protection can have a negative
+   effect on network operations.
+
+   SNMPv1 by itself is such an insecure environment.  Even if the
+   network itself is secure (for example by using IPSec [24]), even
+   then, there is no control as to who on the secure network is allowed
+   to access and SET (change/create/delete) the objects in this MIB.
+
+   It is recommended that the implementers consider the security
+   features as provided by the SNMPv3 framework.  Specifically, the use
+   of the User-based Security Model RFC 2574 [12] and the View-based
+   Access Control Model RFC 2575 [15] is recommended.
+
+   It is then a customer/user responsibility to ensure that the SNMP
+   entity giving access to this MIB, is properly configured to give
+   access to those objects only to those principals (users) that have
+   legitimate rights to access them.
+
+7.  Acknowledgements
+
+   This MIB module was updated based on feedback from the IETF's
+   Interfaces MIB (IF-MIB) and Point-to-Point Protocol Extensions
+   (PPPEXT) Working Groups.
+
+8.  Author's Address
+
+   Dave Thaler
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052-6399
+
+   Phone: +1 425 703 8835
+   EMail: dthaler@microsoft.com
+
+
+
+
+Thaler                      Standards Track                    [Page 12]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+9.  References
+
+   [1]  Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for
+        Describing SNMP Management Frameworks", RFC 2571, April 1999.
+
+   [2]  Rose, M. and K. McCloghrie, "Structure and Identification of
+        Management Information for TCP/IP-based Internets", STD 16, RFC
+        1155, May 1990.
+
+   [3]  Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
+        RFC 1212, March 1991.
+
+   [4]  Rose, M., "A Convention for Defining Traps for use with the
+        SNMP", RFC 1215, March 1991.
+
+   [5]  McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
+        Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
+        April 1999.
+
+   [6]  McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
+        Conventions for SMIv2", STD 58, RFC 2579, April 1999.
+
+   [7]  McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
+        Statements for SMIv2", STD 58, RFC 2580, April 1999.
+
+   [8]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
+        Network Management Protocol", STD 15, RFC 1157, May 1990.
+
+   [9]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+        "Introduction to Community-based SNMPv2", RFC 1901, January
+        1996.
+
+   [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
+        Mappings for Version 2 of the Simple Network Management Protocol
+        (SNMPv2)", RFC 1906, January 1996.
+
+   [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
+        Processing and Dispatching for the Simple Network Management
+        Protocol (SNMP)", RFC 2572, April 1999.
+
+   [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
+        for version 3 of the Simple Network Management Protocol
+        (SNMPv3)", RFC 2574, April 1999.
+
+   [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
+        Operations for Version 2 of the Simple Network Management
+        Protocol (SNMPv2)", RFC 1905, January 1996.
+
+
+
+
+Thaler                      Standards Track                    [Page 13]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+   [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
+        2573, April 1999.
+
+   [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
+        Control Model (VACM) for the Simple Network Management Protocol
+        (SNMP)", RFC 2575, April 1999.
+
+   [16] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
+        Encapsulation (GRE)", RFC 1701, October 1994.
+
+   [17] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
+        Encapsulation over IPv4 networks", RFC 1702, October 1994.
+
+   [18] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
+        1996.
+
+   [19] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
+        October 1996.
+
+   [20] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
+        B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
+        August 1999.
+
+   [21] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little, W. and G.
+        Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
+
+   [22] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
+        2107, February 1997.
+
+   [23] McCloghrie, K. and F. Kastenholz.  "The Interfaces Group MIB
+        using SMIv2", RFC 2233, November 1997.
+
+   [24] R. Atkinson,  "Security architecture for the internet protocol",
+        RFC 2401, November 1998.
+
+   [25] Valencia, A., Littlewood, M. and T. Kolar.  "Cisco Layer Two
+        Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
+
+   [26] D. Provan,  "Tunneling IPX Traffic through IP Networks", RFC
+        1234, June 1991.
+
+   [27] Gilligan, R. and E. Nordmark.  "Transition Mechanisms for IPv6
+        Hosts and Routers", RFC 1933, April 1996.
+
+   [28] Woodburn, R. and D. Mills, "A Scheme for an Internet
+        Encapsulation Protocol: Version 1", RFC 1241, July 1991.
+
+
+
+
+
+Thaler                      Standards Track                    [Page 14]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+   [29] Nichols, K., Blake, S., Baker, F. and D. Black.  "Definition of
+        the Differentiated Services Field (DS Field) in the IPv4 and
+        IPv6 Headers", RFC 2474, December 1998.
+
+
+10.  Intellectual Property Notice
+
+   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 implementers or users of this specification can
+   be obtained from the IETF Secretariat."
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler                      Standards Track                    [Page 15]
+
+RFC 2667                     IP Tunnel MIB                   August 1999
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 implementation 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.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler                      Standards Track                    [Page 16]
+