rfc2851.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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: [phone]
          EMail: [e-mail]

          Brian Haberman
          Nortel Networks
          4039 Emperor Blvd., Suite 200
          Durham, NC  27703, USA

          Phone: [phone]
          EMail: [e-mail]

          Shawn A. Routhier
          Wind River Systems, Inc.
          1 Tara Blvd, Suite 403
          Nashua, NH  03062, USA

          Phone: [phone]
          EMail: [e-mail]



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: [phone]
          EMail: [e-mail]

          Send comments to [e-mail]."

   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.