rfc3291.txt

RFC 的详细文档！

         must fail with an inconsistentValue error.

         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 definition 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:




Daniele, et. al.            Standards Track                     [Page 7]

RFC 3291           TCs for Internet Network Addresses           May 2002


           octets   contents         encoding
            1-4     IPv4 address     network-byte order

         The corresponding InetAddressType value is ipv4(1).

         This textual convention SHOULD NOT be used directly in object
         definitions since it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType as a pair."
    SYNTAX       OCTET STRING (SIZE (4))

InetAddressIPv6 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
    STATUS       current
    DESCRIPTION
        "Represents an IPv6 network address:

           octets   contents         encoding
            1-16    IPv6 address     network-byte order

         The corresponding InetAddressType value is ipv6(2).

         This textual convention SHOULD NOT be used directly in object
         definitions since it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType as a pair."
    SYNTAX       OCTET STRING (SIZE (16))

InetAddressIPv4z ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d%4d"
    STATUS       current
    DESCRIPTION
        "Represents a non-global IPv4 network address together
         with its zone index:

           octets   contents         encoding
            1-4     IPv4 address     network-byte order
            5-8     zone index       network-byte order

         The corresponding InetAddressType value is ipv4z(3).

         The zone index (bytes 5-8) is used to disambiguate identical
         address values on nodes which have interfaces attached to
         different zones of the same scope. The zone index may contain
         the special value 0 which refers to the default zone for each
         scope.

         This textual convention SHOULD NOT be used directly in object



Daniele, et. al.            Standards Track                     [Page 8]

RFC 3291           TCs for Internet Network Addresses           May 2002


         definitions since it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType as a pair."
    SYNTAX OCTET STRING (SIZE (8))

InetAddressIPv6z ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
    STATUS       current
    DESCRIPTION
        "Represents a non-global IPv6 network address together
         with its zone index:

           octets   contents         encoding
            1-16    IPv6 address     network-byte order
           17-20    zone index       network-byte order

         The corresponding InetAddressType value is ipv6z(4).

         The zone index (bytes 17-20) is used to disambiguate
         identical address values on nodes which have interfaces
         attached to different zones of the same scope. The zone index
         may contain the special value 0 which refers to the default
         zone for each scope.

         This textual convention SHOULD NOT be used directly in object
         definitions since it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType as a pair."
    SYNTAX OCTET STRING (SIZE (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.

         This textual convention SHOULD NOT be used directly in object
         definitions since it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType as a pair."
    SYNTAX       OCTET STRING (SIZE (1..255))



Daniele, et. al.            Standards Track                     [Page 9]

RFC 3291           TCs for Internet Network Addresses           May 2002


InetAddressPrefixLength ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "Denotes the length of a generic Internet network address
         prefix. A value of n corresponds to an IP address mask
         which has n contiguous 1-bits from the most significant
         bit (MSB) and all other bits set to 0.

         An InetAddressPrefixLength value is always interpreted within
         the context of an InetAddressType value. Every usage of the
         InetAddressPrefixLength textual convention is required to
         specify the InetAddressType object which provides the
         context.  It is suggested that the InetAddressType object is
         logically registered before the object(s) which use the
         InetAddressPrefixLength textual convention if they appear in
         the same logical row.

         InetAddressPrefixLength values that are larger than
         the maximum length of an IP address for a specific
         InetAddressType are treated as the maximum significant
         value applicable for the InetAddressType. The maximum
         significant value is 32 for the InetAddressType
         'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
         'ipv6(2)' and 'ipv6z(4)'. The maximum significant value
         for the InetAddressType 'dns(16)' is 0.

         The value zero is object-specific and must be defined as
         part of the description of any object which uses this
         syntax. Examples of the usage of zero might include
         situations where the Internet network address prefix
         is unknown or does not apply."
    SYNTAX      Unsigned32

InetPortNumber ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "Represents a 16 bit port number of an Internet transport
         layer protocol. Port numbers are assigned by IANA. A
         current list of all assignments is available from
         <http://www.iana.org/>.

         The value zero is object-specific and must be defined as
         part of the description of any object which uses this
         syntax. Examples of the usage of zero might include
         situations where a port number is unknown, or when the
         value zero is used as a wildcard in a filter."
    REFERENCE  "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"
    SYNTAX      Unsigned32 (0..65535)



Daniele, et. al.            Standards Track                    [Page 10]

RFC 3291           TCs for Internet Network Addresses           May 2002


InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "Represents an autonomous system number which identifies an
         Autonomous System (AS). An AS is a set of routers under a
         single technical administration, using an interior gateway
         protocol and common metrics to route packets within the AS,
         and using an exterior gateway protocol to route packets to
         other ASs'. IANA maintains the AS number space and has
         delegated large parts to the regional registries.

         Autonomous system numbers are currently limited to 16 bits
         (0..65535). There is however work in progress to enlarge the
         autonomous system number space to 32 bits. This textual
         convention therefore uses an Unsigned32 value without a
         range restriction in order to support a larger autonomous
         system number space."
    REFERENCE  "RFC 1771, RFC 1930"
    SYNTAX      Unsigned32

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 in order to express 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) which uses 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



Daniele, et. al.            Standards Track                    [Page 11]

RFC 3291           TCs for Internet Network Addresses           May 2002


   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.

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

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 [19].  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 a zone index is unique [21].

   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).  MIB designers who use
   InetAddressType/InetAddress pairs therefore 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 MIBs (like the TCP-MIB)
   which report addresses in the address family used on the wire, but
   where the entity instrumented obtains such addresses from



Daniele, et. al.            Standards Track                    [Page 12]

RFC 3291           TCs for Internet Network Addresses           May 2002


   applications or administrators in a form which includes a zone index,
   such as v4-mapped IPv6 addresses.

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

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 such objects SHOULD precisely define how
   and when any required name to address resolution is done.

   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
   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 13]

RFC 3291           TCs for Internet Network Addresses           May 2002


   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 }