rfc2851.txt

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

          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