rfc4001.txt

用于snmp协议的mib管理软件


RFC 4001          Internet Network Address Conventions     February 2005


                     interfaceLocal(1),
                     linkLocal(2),
                     subnetLocal(3),
                     adminLocal(4),
                     siteLocal(5), -- site-local unicast addresses
                                   -- have been deprecated by RFC 3879
                     -- unassigned(6),
                     -- unassigned(7),
                     organizationLocal(8),
                     -- unassigned(9),
                     -- unassigned(10),
                     -- unassigned(11),
                     -- unassigned(12),
                     -- unassigned(13),
                     global(14)
                     -- reserved(15)
                 }

InetZoneIndex ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS       current
    DESCRIPTION
        "A zone index identifies an instance of a zone of a
         specific scope.

         The zone index MUST disambiguate identical address
         values.  For link-local addresses, the zone index will
         typically be the interface index (ifIndex as defined in the
         IF-MIB) of the interface on which the address is configured.

         The zone index may contain the special value 0, which refers
         to the default zone.  The default zone may be used in cases
         where the valid zone index is not known (e.g., when a
         management application has to write a link-local IPv6
         address without knowing the interface index value).  The
         default zone SHOULD NOT be used as an easy way out in
         cases where the zone index for a non-global IPv6 address
         is known."
    REFERENCE   "RFC4007"
    SYNTAX       Unsigned32

InetVersion ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
        "A value representing a version of the IP protocol.

         unknown(0)  An unknown or unspecified version of the IP
                     protocol.



Daniele, et al.             Standards Track                    [Page 12]

RFC 4001          Internet Network Address Conventions     February 2005


         ipv4(1)     The IPv4 protocol as defined in RFC 791 (STD 5).

         ipv6(2)     The IPv6 protocol as defined in RFC 2460.

         Note that this textual convention SHOULD NOT be used to
         distinguish different address types associated with IP
         protocols.  The InetAddressType has been designed for this
         purpose."
    REFERENCE   "RFC 791, RFC 2460"
    SYNTAX       INTEGER {
                     unknown(0),
                     ipv4(1),
                     ipv6(2)
                 }
END

4.  Usage Hints

   The InetAddressType and InetAddress textual conventions have been
   introduced to avoid over-constraining an object definition by the use
   of the IpAddress SMI base type, which is IPv4 specific.  An
   InetAddressType/InetAddress pair can represent IP addresses in
   various formats.

   The InetAddressType and InetAddress objects SHOULD NOT be sub-typed
   in object definitions.  Sub-typing 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 indicating that only a subset of the defined
   address types must be implemented to be compliant.

   Every usage of the InetAddress or InetAddressPrefixLength textual
   conventions must specify which InetAddressType object provides the
   context for the interpretation of the InetAddress or
   InetAddressPrefixLength textual convention.

   It is suggested that the InetAddressType object is logically
   registered before the object(s) that use(s) the InetAddress or
   InetAddressPrefixLength textual convention.  An InetAddressType
   object is logically registered before an InetAddress or
   InetAddressPrefixLength object if it appears before the InetAddress
   or InetAddressPrefixLength object in the conceptual row (which
   includes any index objects).  This rule allows programs such as MIB
   compilers to identify the InetAddressType of a given InetAddress or
   InetAddressPrefixLength object by searching for the InetAddressType
   object, which precedes an InetAddress or InetAddressPrefixLength
   object.




Daniele, et al.             Standards Track                    [Page 13]

RFC 4001          Internet Network Address Conventions     February 2005


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 be listed before the InetAddress object
   in the INDEX clause.

   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 look up 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.

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 [RFC3513].  In particular, IPv6 "link-
   local" unicast 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 a zone index is unique [RFC4007].

   The InetAddressIPv6 textual convention has been defined to represent
   global IPv6 addresses and non-global IPv6 addresses in cases where no
   zone index is needed (e.g., on end hosts with a single interface).
   The InetAddressIPv6z textual convention has been defined to represent
   non-global IPv6 addresses in cases where a zone index is needed
   (e.g., a router connecting multiple zones).  Therefore, MIB designers
   who use InetAddressType/InetAddress pairs do not need to define
   additional objects in order to support non-global addresses on nodes
   that connect multiple zones.

   The InetAddressIPv4z is intended for use in MIB modules (such as the
   TCP-MIB) which report addresses in the address family used on the
   wire, but where the entity instrumented obtains these addresses from
   applications or administrators in a form that includes a zone index,
   such as v4-mapped IPv6 addresses.







Daniele, et al.             Standards Track                    [Page 14]

RFC 4001          Internet Network Address Conventions     February 2005


   The size of the zone index has been chosen so that it is consistent
   with (i) the numerical zone index, defined in [RFC4007], and (ii) the
   sin6_scope_id field of the sockaddr_in6 structure, defined in RFC
   2553 [RFC2553].

4.3.  Multiple Addresses 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 accessible by multiple
   InetAddressType/InetAddress pairs.

   If this could be an implementation or usage issue, the DESCRIPTION
   clause of the relevant objects must fully describe which address is
   reported in a given InetAddressType/InetAddress pair.

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, or just
   once when the object was instantiated?

   The DESCRIPTION clause of these objects SHOULD precisely define how
   and when any required name to address resolution is done.

   Similarly, the DESCRIPTION clause of these 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 if the
   MIB module or implementation requires it to map the IP address to a
   DNS 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 in order to satisfy OID length constraints.







Daniele, et al.             Standards Track                    [Page 15]

RFC 4001          Internet Network Address Conventions     February 2005


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
    DESCRIPTION
        "The Internet address for the peer.  The type of this
         address is determined by the value of the peerAddressType
         object.  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



Daniele, et al.             Standards Track                    [Page 16]

RFC 4001          Internet Network Address Conventions     February 2005


         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 compliant
   implementations need only support IPv4/IPv6 addresses without zone
   indices.  Support for DNS names or IPv4/IPv6 addresses with zone
   indices is not required.

   peerCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement of the peer MIB."

       MODULE      -- this module
       MANDATORY-GROUPS    { peerGroup }

       OBJECT  peerAddressType