summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2851.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2851.txt')
-rw-r--r--doc/rfc/rfc2851.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc2851.txt b/doc/rfc/rfc2851.txt
new file mode 100644
index 0000000..f3dad8a
--- /dev/null
+++ b/doc/rfc/rfc2851.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group M. Daniele
+Request for Comments: 2851 Compaq Computer Corporation
+Category: Standards Track B. Haberman
+ Nortel Networks
+ S. Routhier
+ Wind River Systems, Inc.
+ J. Schoenwaelder
+ TU Braunschweig
+ June 2000
+
+
+ Textual Conventions for Internet Network Addresses
+
+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 (2000). All Rights Reserved.
+
+Abstract
+
+ This MIB module defines textual conventions to represent commonly
+ used Internet network layer addressing information. The intent is
+ that these definitions will be imported and used in MIBs that would
+ otherwise define their own representations.
+
+ This work is output from the Operations and Management Area "IPv6MIB"
+ design team.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. The SNMP Management Framework . . . . . . . . . . . . . . . 3
+ 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . 9
+ 4.3 Multiple InetAddresses per Host . . . . . . . . . . . . . . 9
+ 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . 9
+ 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . 10
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . 12
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
+
+
+
+Daniele, et al. Standards Track [Page 1]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ 8. Intellectual Property Notice . . . . . . . . . . . . . . . . 12
+ References . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
+
+1. Introduction
+
+ Several standard-track MIB modules use the IpAddress SMIv2 base type.
+ This limits the applicability of these MIB modules to IP Version 4
+ (IPv4) since the IpAddress SMIv2 base type can only contain 4 byte
+ IPv4 addresses. The IpAddress SMIv2 base type has become problematic
+ with the introduction of IP Version 6 (IPv6) addresses [21].
+
+ This document defines multiple textual conventions as a mechanism to
+ express generic Internet network layer addresses within MIB module
+ specifications. The solution is compatible with SMIv2 (STD 58) and
+ SMIv1 (STD 16). New MIB definitions which need to express network
+ layer Internet addresses SHOULD use the textual conventions defined
+ in this memo. New MIBs SHOULD NOT use the SMIv2 IpAddress base type
+ anymore.
+
+ A generic Internet address consists of two objects, one whose syntax
+ is InetAddressType, and another whose syntax is InetAddress. The
+ value of the first object determines how the value of the second
+ object is encoded. The InetAddress textual convention represents an
+ opaque Internet address value. The InetAddressType enumeration is
+ used to "cast" the InetAddress value into a concrete textual
+ convention for the address type. This usage of multiple textual
+ conventions allows expression of the display characteristics of each
+ address type and makes the set of defined Internet address types
+ extensible.
+
+ The textual conventions defined in this document can be used to
+ define Internet addresses by using DNS domain names in addition to
+ IPv4 and IPv6 addresses. A MIB designer can write compliance
+ statements to express that only a subset of the possible address
+ types must be supported by a compliant implementation.
+
+ MIB developers who need to represent Internet addresses SHOULD use
+ these definitions whenever applicable, as opposed to defining their
+ own constructs. Even MIBs that only need to represent IPv4 or IPv6
+ addresses SHOULD use the textual conventions defined in this memo.
+
+ In order to make existing widely-deployed IPv4-only MIBs fit for
+ IPv6, it might be a valid approach to define separate tables for
+ different address types. This is a decision for the MIB designer.
+ For example, the tcpConnTable of the TCP-MIB [18] was left intact
+
+
+
+
+Daniele, et al. Standards Track [Page 2]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ and a new table was added for TCP connections over IPv6 in the IPV6-
+ TCP-MIB [19]. Note that even in this case, the MIBs SHOULD use the
+ textual conventions defined in this memo.
+
+ Note that MIB developers SHOULD NOT use the textual conventions
+ defined in this document to represent transport layer addresses.
+
+ Instead the SMIv2 TAddress textual convention and associated
+ definitions should be used for transport layer addresses.
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in
+ this document are to be interpreted as described in RFC 2119 [1].
+
+2. The SNMP Management Framework
+
+ The SNMP Management Framework presently consists of five major
+ components:
+
+ o An overall architecture, described in RFC 2571 [2].
+ 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 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The
+ second version, called SMIv2, is described in STD 58, RFC 2578
+ [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8].
+ 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 [9]. A second version of the SNMP
+ message protocol, which is not an Internet standards track
+ protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC
+ 1906 [11]. The third version of the message protocol is called
+ SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574
+ [13].
+ o Protocol operations for accessing management information. The
+ first set of protocol operations and associated PDU formats is
+ described in STD 15, RFC 1157 [9]. A second set of protocol
+ operations and associated PDU formats is described in RFC 1905
+ [14].
+ o A set of fundamental applications described in RFC 2573 [15] and
+ the view-based access control mechanism described in RFC 2575
+ [16].
+
+ A more detailed introduction to the current SNMP Management Framework
+ can be found in RFC 2570 [17].
+
+ 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.
+
+
+
+Daniele, et al. Standards Track [Page 3]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ 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.
+
+3. Definitions
+
+ INET-ADDRESS-MIB DEFINITIONS ::= BEGIN
+
+
+ IMPORTS
+ MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI
+ TEXTUAL-CONVENTION FROM SNMPv2-TC;
+
+
+ inetAddressMIB MODULE-IDENTITY
+ LAST-UPDATED "200006080000Z"
+ ORGANIZATION
+ "IETF Operations and Management Area"
+ CONTACT-INFO
+ "Mike Daniele
+ Compaq Computer Corporation
+ 110 Spit Brook Rd
+ Nashua, NH 03062, USA
+
+ Phone: +1 603 884-1423
+ EMail: daniele@zk3.dec.com
+
+ Brian Haberman
+ Nortel Networks
+ 4039 Emperor Blvd., Suite 200
+ Durham, NC 27703, USA
+
+ Phone: +1 919 992-4439
+ EMail: haberman@nortelnetworks.com
+
+ Shawn A. Routhier
+ Wind River Systems, Inc.
+ 1 Tara Blvd, Suite 403
+ Nashua, NH 03062, USA
+
+ Phone: +1 603 897-2000
+ EMail: sar@epilogue.com
+
+
+
+Daniele, et al. Standards Track [Page 4]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ Juergen Schoenwaelder
+ TU Braunschweig
+ Bueltenweg 74/75
+ 38106 Braunschweig, Germany
+
+ Phone: +49 531 391-3289
+ EMail: schoenw@ibr.cs.tu-bs.de
+
+ Send comments to mibs@ops.ietf.org."
+
+ DESCRIPTION
+ "This MIB module defines textual conventions for
+ representing Internet addresses. An Internet
+ address can be an IPv4 address, an IPv6 address
+ or a DNS domain name."
+
+ REVISION "200006080000Z"
+ DESCRIPTION
+ "Initial version, published as RFC 2851."
+ ::= { mib-2 76 }
+
+ InetAddressType ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "A value that represents a type of Internet address.
+
+ unknown(0) An unknown address type. This value MUST
+ be used if the value of the corresponding
+ InetAddress object is a zero-length string.
+ It may also be used to indicate an IP address
+ which is not in one of the formats defined
+ below.
+
+ ipv4(1) An IPv4 address as defined by the
+ InetAddressIPv4 textual convention.
+
+ ipv6(2) An IPv6 address as defined by the
+ InetAddressIPv6 textual convention.
+
+ dns(16) A DNS domain name as defined by the
+ InetAddressDNS textual convention.
+
+ Each definition of a concrete InetAddressType value must be
+ accompanied by a definition of a textual convention for use
+ with that InetAddressType.
+
+ The InetAddressType textual convention SHOULD NOT be subtyped
+ in object type definitions to support future extensions. It
+
+
+
+Daniele, et al. Standards Track [Page 5]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ MAY be subtyped in compliance statements in order to require
+ only a subset of these address types for a compliant
+ implementation."
+ SYNTAX INTEGER {
+ unknown(0),
+ ipv4(1), -- these named numbers are aligned
+ ipv6(2), -- with AddressFamilyNumbers from
+ dns(16) -- IANA-ADDRESS-FAMILY-NUMBERS-MIB
+ }
+
+ InetAddress ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Denotes a generic Internet address.
+
+ An InetAddress value is always interpreted within the
+ context of an InetAddressType value. The InetAddressType
+ object which defines the context must be registered
+ immediately before the object which uses the InetAddress
+ textual convention. In other words, the object identifiers
+ for the InetAddressType object and the InetAddress object
+ MUST have the same length and the last sub-identifier of
+ the InetAddressType object MUST be 1 less than the last
+ sub-identifier of the InetAddress object.
+
+ When this textual convention is used as the syntax of an
+ index object, there may be issues with the limit of 128
+ sub-identifiers specified in SMIv2, STD 58. In this case,
+ the OBJECT-TYPE declaration MUST include a 'SIZE' clause
+ to limit the number of potential instance sub-identifiers."
+ SYNTAX OCTET STRING (SIZE (0..255))
+
+ InetAddressIPv4 ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "1d.1d.1d.1d"
+ STATUS current
+ DESCRIPTION
+ "Represents an IPv4 network address:
+
+ octets contents encoding
+ 1-4 IP address network-byte order
+
+ The corresponding InetAddressType value is ipv4(1)."
+ SYNTAX OCTET STRING (SIZE (4))
+
+ InetAddressIPv6 ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
+ STATUS current
+ DESCRIPTION
+
+
+
+Daniele, et al. Standards Track [Page 6]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ "Represents an IPv6 network address:
+
+ octets contents encoding
+ 1-16 IPv6 address network-byte order
+ 17-20 scope identifier network-byte order
+
+ The corresponding InetAddressType value is ipv6(2).
+
+ The scope identifier (bytes 17-20) MUST NOT be present
+ for global IPv6 addresses. For non-global IPv6 addresses
+ (e.g. link-local or site-local addresses), the scope
+ identifier MUST always be present. It contains a link
+ identifier for link-local and a site identifier for
+ site-local IPv6 addresses.
+
+ The scope identifier MUST disambiguate identical address
+ values. For link-local addresses, the scope identifier will
+ typically be the interface index (ifIndex as defined in the
+ IF-MIB, RFC 2233) of the interface on which the address is
+ configured.
+
+ The scope identifier may contain the special value 0
+ which refers to the default scope. The default scope
+ may be used in cases where the valid scope identifier
+ is not known (e.g., a management application needs to
+ write a site-local InetAddressIPv6 address without
+ knowing the site identifier value). The default scope
+ SHOULD NOT be used as an easy way out in cases where
+ the scope identifier for a non-global IPv6 is known."
+ SYNTAX OCTET STRING (SIZE (16|20))
+
+ InetAddressDNS ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "255a"
+ STATUS current
+ DESCRIPTION
+ "Represents a DNS domain name. The name SHOULD be
+ fully qualified whenever possible.
+
+ The corresponding InetAddressType is dns(16).
+
+ The DESCRIPTION clause of InetAddress objects that
+ may have InetAddressDNS values must fully describe
+ how (and when) such names are to be resolved to IP
+ addresses."
+ SYNTAX OCTET STRING (SIZE (1..255))
+
+ END
+
+
+
+
+Daniele, et al. Standards Track [Page 7]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+4. Usage Hints
+
+ One particular usage of InetAddressType/InetAddress pairs is to avoid
+ over-constraining an object definition by the use of the IpAddress
+ SMI base type. An InetAddressType/InetAddress pair allows to
+ represent IP addresses in various formats.
+
+ The InetAddressType and InetAddress objects SHOULD NOT be subtyped.
+ Subtyping binds the MIB module to specific address formats, which may
+ cause serious problems if new address formats need to be introduced.
+ Note that it is possible to write compliance statements in order to
+ express that only a subset of the defined address types must be
+ implemented to be compliant.
+
+ Internet addresses MUST always be represented by a pair of
+ InetAddressType/InetAddress objects. It is not allowed to "share" an
+ InetAddressType between multiple InetAddress objects. Furthermore,
+ the InetAddressType object must be registered immediately before the
+ InetAddress object. In other words, the object identifiers for the
+ InetAddressType object and the InetAddress object MUST have the same
+ length and the last sub-identifier of the InetAddressType object MUST
+ be 1 less than the last sub-identifier of the InetAddress object.
+
+4.1 Table Indexing
+
+ When a generic Internet address is used as an index, both the
+ InetAddressType and InetAddress objects MUST be used. The
+ InetAddressType object MUST come immediately before the InetAddress
+ object in the INDEX clause. If multiple Internet addresses are used
+ in the INDEX clause, then every Internet address must be represented
+ by a pair of InetAddressType and InetAddress objects.
+
+ The IMPLIED keyword MUST NOT be used for an object of type
+ InetAddress in an INDEX clause. Instance sub-identifiers are then of
+ the form T.N.O1.O2...On, where T is the value of the InetAddressType
+ object, O1...On are the octets in the InetAddress object, and N is
+ the number of those octets.
+
+ There is a meaningful lexicographical ordering to tables indexed in
+ this fashion. Command generator applications may lookup specific
+ addresses of known type and value, issue GetNext requests for
+ addresses of a single type, or issue GetNext requests for a specific
+ type and address prefix.
+
+
+
+
+
+
+
+
+Daniele, et al. Standards Track [Page 8]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+4.2 Uniqueness of Addresses
+
+ IPv4 addresses were intended to be globally unique, current usage
+ notwithstanding. IPv6 addresses were architected to have different
+ scopes and hence uniqueness [21]. In particular, IPv6 "link-local"
+ and "site-local" addresses are not guaranteed to be unique on any
+ particular node. In such cases, the duplicate addresses must be
+ configured on different interfaces. So the combination of an IPv6
+ address and an interface number is unique. The interface number may
+ therefore be used as a scope identifier.
+
+ The InetAddressIPv6 textual convention has been defined to represent
+ global and non-global IPv6 addresses. MIB designers who use
+ InetAddressType/InetAddress pairs therefore do not need define
+ additional objects in order to support link-local or site-local
+ addresses.
+
+ The size of the scope identifier has been chosen so that it matches
+ the sin6_scope_id field of the sockaddr_in6 structure defined in RFC
+ 2553 [22].
+
+4.3 Multiple InetAddresses per Host
+
+ A single host system may be configured with multiple addresses (IPv4
+ or IPv6), and possibly with multiple DNS names. Thus it is possible
+ for a single host system to be represented by multiple
+ InetAddressType/InetAddress pairs.
+
+ If this could be an implementation or usage issue, then the
+ DESCRIPTION clause of the relevant objects MUST fully describe
+ required behavior.
+
+4.4 Resolving DNS Names
+
+ DNS names must be resolved to IP addresses when communication with
+ the named host is required. This raises a temporal aspect to defining
+ MIB objects whose value is a DNS name: When is the name translated to
+ an address?
+
+ For example, consider an object defined to indicate a forwarding
+ destination, and whose value is a DNS name. When does the forwarding
+ entity resolve the DNS name? Each time forwarding occurs? Once, when
+ the object was instantiated?
+
+ The DESCRIPTION clause of such objects SHOULD precisely define how
+ and when any required name to address resolution is done.
+
+
+
+
+
+Daniele, et al. Standards Track [Page 9]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ Similarly, the DESCRIPTION clause of such objects SHOULD precisely
+ define how and when a reverse lookup is being done if an agent has
+ accessed instrumentation that knows about an IP address and the MIB
+ or implementation requires to map the address to a name.
+
+5. Table Indexing Example
+
+ This example shows a table listing communication peers that are
+ identified by either an IPv4 address, an IPv6 address or a DNS name.
+ The table definition also prohibits entries with an empty address
+ (whose type would be "unknown"). The size of a DNS name is limited to
+ 64 characters.
+
+ peerTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF PeerEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A list of communication peers."
+ ::= { somewhere 1 }
+
+ peerEntry OBJECT-TYPE
+ SYNTAX PeerEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry containing information about a particular peer."
+ INDEX { peerAddressType, peerAddress }
+ ::= { peerTable 1 }
+
+ PeerEntry ::= SEQUENCE {
+ peerAddressType InetAddressType,
+ peerAddress InetAddress,
+ peerStatus INTEGER }
+
+ peerAddressType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The type of Internet address by which the peer
+ is reachable."
+ ::= { peerEntry 1 }
+
+ peerAddress OBJECT-TYPE
+ SYNTAX InetAddress (SIZE (1..64))
+ MAX-ACCESS not-accessible
+ STATUS current
+
+
+
+Daniele, et al. Standards Track [Page 10]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ DESCRIPTION
+ "The Internet address for the peer. Note that
+ implementations must limit themselves to a single
+ entry in this table per reachable peer.
+
+ The peerAddress may not be empty due to the SIZE
+ restriction.
+
+ If a row is created administratively by an SNMP
+ operation and the address type value is dns(16), then
+ the agent stores the DNS name internally. A DNS name
+ lookup must be performed on the internally stored DNS
+ name whenever it is being used to contact the peer.
+ If a row is created by the managed entity itself and
+ the address type value is dns(16), then the agent
+ stores the IP address internally. A DNS reverse lookup
+ must be performed on the internally stored IP address
+ whenever the value is retrieved via SNMP."
+ ::= { peerEntry 2 }
+
+ The following compliance statement specifies that implementations
+ need only support IPv4 addresses and globally unique IPv6 addresses
+ to be compliant. Support for DNS names or scoped IPv6 addresses is
+ not required.
+
+ peerCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement the peer MIB."
+
+ MODULE -- this module
+ MANDATORY-GROUPS { peerGroup }
+
+ OBJECT peerAddressType
+ SYNTAX InetAddressType { ipv4(1), ipv6(2) }
+ DESCRIPTION
+ "An implementation is only required to support IPv4
+ and IPv6 addresses."
+
+ OBJECT peerAddress
+ SYNTAX InetAddress (SIZE(4|16))
+ DESCRIPTION
+ "An implementation is only required to support IPv4
+ and globally unique IPv6 addresses."
+
+ ::= { somewhere 2 }
+
+
+
+
+
+Daniele, et al. Standards Track [Page 11]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ Note that the SMIv2 does not permit inclusion of not-accessible
+ objects in an object group (see section 3.1 in STD 58, RFC 2580 [8]).
+ It is therefore not possible to formally refine the syntax of
+ auxiliary objects which are not-accessible. In such a case, it is
+ suggested to express the refinement informally in the DESCRIPTION
+ clause of the MODULE-COMPLIANCE macro invocation.
+
+6. Security Considerations
+
+ This module does not define any management objects. Instead, it
+ defines a set of textual conventions which may be used by other MIB
+ modules to define management objects.
+
+ Meaningful security considerations can only be written in the modules
+ that define management objects.
+
+7. Acknowledgments
+
+ The authors would like to thank Randy Bush, Richard Draves, Mark
+ Ellison, Bill Fenner, Jun-ichiro Hagino, Tim Jenkins, Glenn
+ Mansfield, Keith McCloghrie, Thomas Narten, Erik Nordmark, Peder Chr.
+ Norgaard, Randy Presuhn, Andrew Smith, Dave Thaler, Kenneth White,
+ Bert Wijnen, and Brian Zill for their comments and suggestions.
+
+8. 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 implementors 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.
+
+
+
+
+
+
+Daniele, et al. Standards Track [Page 12]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
+ Describing SNMP Management Frameworks", RFC 2571, April 1999.
+
+ [3] Rose, M. and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based Internets", STD 16, RFC
+ 1155, May 1990.
+
+ [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
+ RFC 1212, March 1991.
+
+ [5] Rose, M., "A Convention for Defining Traps for use with the
+ SNMP", RFC 1215, March 1991.
+
+ [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+ M. and S. Waldbusser, "Structure of Management Information
+ Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
+
+ [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+ M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
+ RFC 2579, April 1999.
+
+ [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+ M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
+ 58, RFC 2580, April 1999.
+
+ [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
+ Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
+
+ [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Introduction to Community-based SNMPv2", RFC 1901, January
+ 1996.
+
+ [11] 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.
+
+ [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
+ Processing and Dispatching for the Simple Network Management
+ Protocol (SNMP)", RFC 2572, April 1999.
+
+ [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
+ for version 3 of the Simple Network Management Protocol
+ (SNMPv3)", RFC 2574, April 1999.
+
+
+
+Daniele, et al. Standards Track [Page 13]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+ [14] 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.
+
+ [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
+ 2573, April 1999.
+
+ [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
+ Control Model (VACM) for the Simple Network Management
+ Protocol (SNMP)", RFC 2575, April 1999.
+
+ [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
+ to Version 3 of the Internet-standard Network Management
+ Framework", RFC 2570, April 1999.
+
+ [18] McCloghrie, K., "SNMPv2 Management Information Base for the
+ Transmission Control Protocol using SMIv2", RFC 2012, November
+ 1996.
+
+ [19] Daniele, M., "IP Version 6 Management Information Base for the
+ Transmission Control Protocol", RFC 2452, December 1998.
+
+ [20] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
+ using SMIv2", RFC 2233, November 1997.
+
+ [21] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [22] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
+ Socket Interface Extensions for IPv6", RFC 2553, March 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daniele, et al. Standards Track [Page 14]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+Authors' Addresses
+
+ Mike Daniele
+ Compaq Computer Corporation
+ 110 Spit Brook Rd
+ Nashua, NH 03062
+ USA
+
+ Phone: +1 603 884-1423
+ EMail: daniele@zk3.dec.com
+
+ Brian Haberman
+ Nortel Networks
+ 4039 Emperor Blvd., Suite 200
+ Durham, NC 27703
+ USA
+
+ Phone: +1 919 992-4439
+ EMail: haberman@nortelnetworks.com
+
+ Shawn A. Routhier
+ Wind River Systems, Inc.
+ 1 Tara Blvd, Suite 403
+ Nashua, NH 03062
+ USA
+
+ Phone: +1 603 897-2000
+ EMail: sar@epilogue.com
+
+ Juergen Schoenwaelder
+ TU Braunschweig
+ Bueltenweg 74/75
+ 38106 Braunschweig
+ Germany
+
+ Phone: +49 531 391-3289
+ EMail: schoenw@ibr.cs.tu-bs.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daniele, et al. Standards Track [Page 15]
+
+RFC 2851 TCs for Internet Network Addresses June 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daniele, et al. Standards Track [Page 16]
+