RFC 3796 - Survey of IPv4 Addresses in Currently Deployed IE(3)

时间:2006-10-30 来源: 作者: 点击:
TheMIBdefinedbythismemosupportsuseofbothIPv4andIPv6 addressing. ThisspecificationisbothIPv4andIPv6aware. 5.62.RFC2562DefinitionsofProtocolandManagedObjectsfor TN3270EResponseTimeCollectionUsingSMIv2
  

   The MIB defined by this memo supports use of both IPv4 and IPv6
   addressing.

   This specification is both IPv4 and IPv6 aware.

5.62.  RFC 2562 Definitions of Protocol and Managed Objects for
       TN3270E Response Time Collection Using SMIv2

   This MIB module inherits IP version-independence by virtue of
   importing the appropriate definitions from RFC 2561.

5.63.  RFC 2564 Application Management MIB

   The following textual convention is defined:

   ApplTAddress ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
             "Denotes a transport service address.

             For snmpUDPDomain, an ApplTAddress is 6 octets long,

             the initial 4 octets containing the IP-address in
             network-byte order and the last 2 containing the UDP
             port in network-byte order.  Consult ’Transport Mappings
             for Version 2 of the Simple Network Management Protocol
             (SNMPv2)’ for further information on snmpUDPDomain."
       SYNTAX       OCTET STRING (SIZE (0..255))

   A new TC should be defined to handle IPv6 addresses.

5.64.  RFC 2584 Definitions of Managed Objects for APPN/HPR in
       IP Networks

   Many of the object definitions described in this document assume the
   use of the IPv4 only TOS header bits.  It is therefore IPv4-only in
   nature and will not support IPv6.

5.65.  RFC 2594 Definitions of Managed Objects for WWW Services

   There are no IPv4 dependencies in this specification.

5.66.  RFC 2605 Directory Server Monitoring MIB

   There are no IPv4 dependencies in this specification.

5.67.  RFC 2613 Remote Network Monitoring MIB Extensions for
       Switched Networks Version 1.0

   There are no IPv4 dependencies in this specification.

5.68.  RFC 2618 RADIUS Authentication Client MIB

   This RFC defines the following objects:

   RadiusAuthServerEntry ::= SEQUENCE {
         radiusAuthServerIndex                           Integer32,
         radiusAuthServerAddress                         IpAddress,
         radiusAuthClientServerPortNumber                Integer32,
         radiusAuthClientRoundTripTime                   TimeTicks,
         radiusAuthClientAccessRequests                  Counter32,
         radiusAuthClientAccessRetransmissions           Counter32,
         radiusAuthClientAccessAccepts                   Counter32,
         radiusAuthClientAccessRejects                   Counter32,
         radiusAuthClientAccessChallenges                Counter32,
         radiusAuthClientMalformedAccessResponses        Counter32,
         radiusAuthClientBadAuthenticators               Counter32,
         radiusAuthClientPendingRequests                   Gauge32,
         radiusAuthClientTimeouts                        Counter32,
         radiusAuthClientUnknownTypes                    Counter32,

         radiusAuthClientPacketsDropped                  Counter32
   }

   radiusAuthServerAddress OBJECT-TYPE
         SYNTAX     IpAddress
         MAX-ACCESS read-only
         STATUS     current
         DESCRIPTION
               "The IP address of the RADIUS authentication server
                referred to in this table entry."
         ::= { radiusAuthServerEntry 2 }

   There needs to be an update to allow an IPv6 based object for this
   value.

5.69.  RFC 2619 RADIUS Authentication Server MIB

   This MIB defines the followings objects:

   RadiusAuthClientEntry ::= SEQUENCE {
          radiusAuthClientIndex                           Integer32,
          radiusAuthClientAddress                         IpAddress,
          radiusAuthClientID                        SnmpAdminString,
          radiusAuthServAccessRequests                    Counter32,
          radiusAuthServDupAccessRequests                 Counter32,
          radiusAuthServAccessAccepts                     Counter32,
          radiusAuthServAccessRejects                     Counter32,
          radiusAuthServAccessChallenges                  Counter32,
          radiusAuthServMalformedAccessRequests           Counter32,
          radiusAuthServBadAuthenticators                 Counter32,
          radiusAuthServPacketsDropped                    Counter32,
          radiusAuthServUnknownTypes                      Counter32
   }

   radiusAuthClientAddress OBJECT-TYPE
          SYNTAX     IpAddress
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
                "The NAS-IP-Address of the RADIUS authentication client
                 referred to in this table entry."
          ::= { radiusAuthClientEntry 2 }

   This object needs to be deprecated and replaced by one that supports
   both IPv4 and IPv6 addresses.

5.70.  RFC 2622 Routing Policy Specification Language (RPSL)

   The only objects in the version of RPSL that deal with IP addresses
   are defined as:

   <ipv4-address> An IPv4 address is represented as a sequence of four
      integers in the range from 0 to 255 separated by the character dot
      ".".  For example, 128.9.128.5 represents a valid IPv4 address.
      In the rest of this document, we may refer to IPv4 addresses as IP
      addresses.

   <address-prefix> An address prefix is represented as an IPv4 address
      followed by the character slash "/" followed by an integer in the
      range from 0 to 32.  The following are valid address prefixes:
      128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address
      prefixes are invalid:  0/0, 128.9/16 since 0 or 128.9 are not
      strings containing four integers.

   There seems to be an awareness of IPv6 because of the terminology but
   it is not specifically defined.  Therefore additional objects for
   IPv6 addresses and prefixes need to be defined.

5.71.  RFC 2662 Definitions of Managed Objects for the ADSL Lines

   There are no IPv4 dependencies in this specification.

5.72.  RFC 2667 IP Tunnel MIB

   The Abstract of this document says:

      This memo defines a Management Information Base (MIB) for use with
      network management protocols in the Internet community.  In
      particular, it describes managed objects used for managing tunnels
      of any type over IPv4 networks.  Extension MIBs may be designed
      for managing protocol-specific objects.  Likewise, extension MIBs
      may be designed for managing security-specific objects.  This MIB
      does not support tunnels over non-IPv4 networks (including IPv6
      networks).  Management of such tunnels may be supported by other
      MIBs.

   A similar MIB for tunneling over IPv6 should be defined.

5.73.  RFC 2669 DOCSIS Cable Device MIB Cable Device Management
       Information Base for DOCSIS compliant Cable Modems and
       Cable Modem Termination Systems

   This document states:

      Please note that the DOCSIS 1.0 standard only requires Cable
      Modems to implement SNMPv1 and to process IPv4 customer traffic.
      Design choices in this MIB reflect those requirements.  Future
      versions of the DOCSIS standard are expected to require support
      for SNMPv3 and IPv6 as well.

5.74.  RFC 2670 Radio Frequency (RF) Interface Management Information
       Base for MCNS/DOCSIS compliant RF interfaces

      This MIB defines the following objects:

DocsIfCmtsCmStatusEntry ::= SEQUENCE {
            docsIfCmtsCmStatusIndex               Integer32,
            docsIfCmtsCmStatusMacAddress          MacAddress,
            docsIfCmtsCmStatusIpAddress           IpAddress,
            docsIfCmtsCmStatusDownChannelIfIndex  InterfaceIndexOrZero,
            docsIfCmtsCmStatusUpChannelIfIndex    InterfaceIndexOrZero,
            docsIfCmtsCmStatusRxPower             TenthdBmV,
            docsIfCmtsCmStatusTimingOffset        Unsigned32,
            docsIfCmtsCmStatusEqualizationData    OCTET STRING,
            docsIfCmtsCmStatusValue               INTEGER,
            docsIfCmtsCmStatusUnerroreds          Counter32,
            docsIfCmtsCmStatusCorrecteds          Counter32,
            docsIfCmtsCmStatusUncorrectables      Counter32,
            docsIfCmtsCmStatusSignalNoise         TenthdB,
            docsIfCmtsCmStatusMicroreflections    Integer32
        }

docsIfCmtsCmStatusIpAddress OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "IP address of this Cable Modem.  If the Cable Modem has no
             IP address assigned, or the IP address is unknown, this
             object returns a value of 0.0.0.0.  If the Cable Modem has
             multiple IP addresses, this object returns the IP address
             associated with the Cable interface."
        ::= { docsIfCmtsCmStatusEntry 3 }

   This object needs to be deprecated and replaced by one that supports
   both IPv4 and IPv6 addresses.

5.75.  RFC 2674 Definitions of Managed Objects for Bridges with
       Traffic Classes, Multicast Filtering and Virtual LAN
       Extensions

   There are no IPv4 dependencies in this specification.

5.76.  RFC 2677 Definitions of Managed Objects for the NBMA Next
       Hop Resolution Protocol (NHRP)

   There are no IPv4 dependencies in this specification.

5.77.  RFC 2720 Traffic Flow Measurement: Meter MIB

   This specification is both IPv4 and IPv6 aware and needs no changes.

5.78.  RFC 2725 Routing Policy System Security

   There are no IPv4 dependencies in this specification.

5.79.  RFC 2726 PGP Authentication for RIPE Database Updates

   There are no IPv4 dependencies in this specification.

5.80.  RFC 2737 Entity MIB (Version 2)

   There are no IPv4 dependencies in this specification.

5.81.  RFC 2741 Agent Extensibility (AgentX) Protocol Version 1

   Although the examples in the document are for IPv4 transport only,
   there is no IPv4 dependency in the AgentX protocol itself.

5.82.  RFC 2742 Definitions of Managed Objects for Extensible SNMP
       Agents

   There are no IPv4 dependencies in this specification.

5.83.  RFC 2748 The COPS (Common Open Policy Service) Protocol

   This specification is both IPv4 and IPv6 aware and needs no changes.

5.84.  RFC 2749 COPS usage for RSVP

   There are no IPv4 dependencies in this specification.

5.85.  RFC 2769 Routing Policy System Replication

   There are no IPv4 dependencies in this specification.

5.86.  RFC 2787 Definitions of Managed Objects for the Virtual
       Router Redundancy Protocol

   As stated in the Overview section:

      Since the VRRP protocol is intended for use with IPv4 routers
      only, this MIB uses the SYNTAX for IP addresses which is specific
      to IPv4.  Thus, changes will be required for this MIB to
      interoperate in an IPv6 environment.

5.87.  RFC 2788 Network Services Monitoring MIB

   There are no IPv4 dependencies in this specification.

5.88.  RFC 2789 Mail Monitoring MIB

   There are no IPv4 dependencies in this specification.

5.89.  RFC 2837 Definitions of Managed Objects for the Fabric Element
       in Fibre Channel Standard

   There are no IPv4 dependencies in this specification.

5.90.  RFC 2856 Textual Conventions for Additional High Capacity
       Data Types

   There are no IPv4 dependencies in this specification.

5.91.  RFC 2864 The Inverted Stack Table Extension to the Interfaces
       Group MIB

   There are no IPv4 dependencies in this specification.

5.92.  RFC 2895 Remote Network Monitoring MIB Protocol Identifier
       Reference

   This specification is both IPv4 and IPv6 aware and needs no changes.

5.93.  RFC 2925 Definitions of Managed Objects for Remote
       Ping, Traceroute, and Lookup Operations

   This MIB mostly is IPv4 and IPv6 aware.  There are a few assumptions
   that are problems, though.  In the following object definitions:

   pingCtlDataSize OBJECT-TYPE
      SYNTAX      Unsigned32 (0..65507)
      UNITS       "octets"
      MAX-ACCESS  read-create

      STATUS      current
      DESCRIPTION
          "Specifies the size of the data portion to be
          transmitted in a ping operation in octets.  A ping
          request is usually an ICMP message encoded
          into an IP packet.  An IP packet has a maximum size
          of 65535 octets.  Subtracting the size of the ICMP
          or UDP header (both 8 octets) and the size of the IP
          header (20 octets) yields a maximum size of 65507
          octets."
      DEFVAL { 0 }
      ::= { pingCtlEntry 5 }

   traceRouteCtlDataSize OBJECT-TYPE
      SYNTAX      Unsigned32 (0..65507)
      UNITS       "octets"
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "Specifies the size of the data portion of a traceroute
          request in octets.  A traceroute request is essentially
          transmitted by encoding a UDP datagram into a
          IP packet.  So subtracting the size of a UDP header
          (8 octets) and the size of a IP header (20 octets)
          yields a maximum of 65507 octets."
      DEFVAL { 0 }
      ::= { traceRouteCtlEntry 6 }

   The DESCRIPTION clauses need to be updated to remove the IPv4
   dependencies.

5.94.  RFC 2932 IPv4 Multicast Routing MIB

   This specification is only defined for IPv4 and a similar MIB must be
   defined for IPv6.

5.95.  RFC 2933 Internet Group Management Protocol MIB

   As stated in this document:

      Since IGMP is specific to IPv4, this MIB does not support
      management of equivalent functionality for other address families,
      such as IPv6.

5.96.  RFC 2940 Definitions of Managed Objects for Common
       Open Policy Service (COPS) Protocol Clients

   This MIB is both IPv4 and IPv6 aware and needs no changes.

5.97.  RFC 2954 Definitions of Managed Objects for Frame
       Relay Service

   There are no IPv4 dependencies in this specification.

5.98.  RFC 2955 Definitions of Managed Objects for Monitoring
       and Controlling the Frame Relay/ATM PVC Service
       Interworking Function

   There are no IPv4 dependencies in this specification.

5.99.  RFC 2959 Real-Time Transport Protocol Management Information Base

   There are no IPv4 dependencies in this specification.

5.100.  RFC 2981 Event MIB

   There are no IPv4 dependencies in this specification.

5.101.  RFC 2982 Distributed Management Expression MIB

   There are no IPv4 dependencies in this specification.

5.102.  RFC 3014 Notification Log MIB

   There are no IPv4 dependencies in this specification.

5.103.  RFC 3019 IP Version 6 Management Information Base for
        The Multicast Listener Discovery Protocol

   This is an IPv6 related document and is not discussed in this
   document.

5.104.  RFC 3020 Definitions of Managed Objects for Monitoring
        and Controlling the UNI/NNI Multilink Frame Relay Function

   There are no IPv4 dependencies in this specification.

5.105.  RFC 3055 Management Information Base for the PINT Services
        Architecture

   There are no IPv4 dependencies in this specification.

5.106.  RFC 3060 Policy Core Information Model -- Version 1
        Specification (CIM)

   There are no IPv4 dependencies in this specification.

5.107.  RFC 3084 COPS Usage for Policy Provisioning (COPS-PR)

   This specification builds on RFC 2748, and is both IPv4 and IPv6
   capable.  The specification defines a sample filter in section 4.3,
   which has "ipv4" in it.

5.108.  RFC 3165 Definitions of Managed Objects for the Delegation of
        Management Scripts

   There are no IPv4 dependencies in this specification.

5.109.  RFC 3231 Definitions of Managed Objects for Scheduling
        Management Operations

   There are no IPv4 dependencies in this specification.

5.110.  RFC 3291 Textual Conventions for Internet Network Addresses

   There are no IPv4 dependencies in this specification.

5.111.  RFC 3635 Definitions of Managed Objects for the
        Ethernet-like Interface Types

   There are no IPv4 dependencies in this specification.

5.112.  RFC 3636 Definitions of Managed Objects for IEEE 802.3 Medium
        Attachment Units (MAUs)

   There are no IPv4 dependencies in this specification.

6.  Experimental RFCs

   Experimental RFCs typically define protocols that do not have
   widescale implementation or usage on the Internet.  They are often
   propriety in nature or used in limited arenas.  They are documented
   to the Internet community in order to allow potential
   interoperability or some other potential useful scenario.  In a few
   cases, they are presented as alternatives to the mainstream solution
   to an acknowledged problem.

6.1.  RFC 1187 Bulk Table Retrieval with the SNMP

   There are no IPv4 dependencies in this specification.

6.2.  RFC 1224 Techniques for managing asynchronously generated
      alerts

   There are no IPv4 dependencies in this specification.

6.3.  RFC 1238 CLNS MIB for use with Connectionless Network Protocol
      (ISO 8473) and End System to Intermediate System (ISO 9542)

   There are no IPv4 dependencies in this specification.

6.4.  RFC 1592 Simple Network Management Protocol Distributed Protocol
      Interface Version 2.0

   There are no IPv4 dependencies in this specification.

6.5.  RFC 1792 TCP/IPX Connection Mib Specification

   There are no IPv4 dependencies in this specification.

6.6.  RFC 2724 RTFM: New Attributes for Traffic Flow Measurement

   There are no IPv4 dependencies in this specification.

6.7.  RFC 2758 Definitions of Managed Objects for Service Level
      Agreements Performance Monitoring

   This specification is both IPv4 and IPv6 aware and needs no changes.

6.8.  RFC 2786 Diffie-Helman USM Key Management Information Base and
      Textual Convention

   There are no IPv4 dependencies in this specification.

6.9.  RFC 2903 Generic AAA Architecture

   There are no IPv4 dependencies in this specification.

6.10.  RFC 2934 Protocol Independent Multicast MIB for IPv4

   This document is specific to IPv4.

6.11.  RFC 3179 Script MIB Extensibility Protocol Version 1.1

   There are no IPv4 dependencies in this specification.

7.  Summary of Results

   In the initial survey of RFCs, 36 positives were identified out of a
   total of 153, broken down as follows:

         Standards:                         6 out of  15 or 40.00%
         Draft Standards:                   4 out of  15 or 26.67%
         Proposed Standards:               26 out of 112 or 23.21%
         Experimental RFCs:                 0 out of  11 or  0.00%

   Of those identified, many require no action because they document
   outdated and unused protocols, while others are document protocols
   that are actively being updated by the appropriate working groups.
   Additionally there are many instances of standards that should be
   updated but do not cause any operational impact if they are not
   updated.  The remaining instances are documented below.

7.1.  Standards

7.1.1.  STD 16, Structure of Management Information (RFCs 1155 and 1212)

   RFC 1155 and RFC 1212 (along with the informational document RFC
   1215) define SMIv1.  These documents have been superseded by RFCs
   2578, 2579, and 2580 which define SMIv2.  Since SMIv1 is no longer
   being used as the basis for new IETF MIB modules, the limitations
   identified in this Internet Standard do not require any action.

7.1.2.  STD 17 Simple Network Management Protocol (RFC 1213)

   The limitations identified have been addressed, because RFC 1213 has
   been split into multiple modules which are all IPv6 capable.

7.2.  Draft Standards

7.2.1.  BGP4 MIB (RFC 1657)

   This problem is currently being addressed by the Inter Domain Routing
   (IDR) WG [2].

7.2.2.  SMDS MIB (RFC 1694)

   See Internet Area standards.  Once a specification for IPv6 over SMDS
   is created a new MIB must be defined.

7.2.3.  RIPv2 MIB (RFC 1724)

   There is no updated MIB module to cover the problems outlined.  A new
   MIB module should be defined.

7.2.4.  OSPFv2 MIB (RFC 1850)

   This problem is currently being addressed by the OSPF WG [3].

7.2.5.  Transport MIB (RFC 1906)

   RFC 1906 has been obsoleted by RFC 3417, Transport Mappings for SNMP,
   and the limitations of this specification have been addressed by that
   RFC, which defines TCs that can be used to specify transport domains
   in an IP version-independent way.  RFC 3419 recommends that those TCs
   be used in place of SnmpUDPAddress when IPv6 support is required and
   for all new applications that are not SNMP-specific.

7.3.  Proposed Standards

7.3.1.  MIB for Multiprotocol Interconnect over X.25 (RFC 1461)

   This problem has not been addressed.  If a user requirement for IPv6
   over X.25 develops (which is thought to be unlikely) then this MIB
   module will need to be updated in order to accommodate it.

7.3.2.  PPP IPCP MIB (RFC 1473)

   There is no updated MIB to cover the problems outlined.  A new MIB
   should be defined.

7.3.3.  Appletalk MIB (RFC 1742)

   This problem has not been addressed.  If a user requirement for IPv6
   over Appletalk develops (which is thought to be unlikely) then this
   MIB module will need to be updated (or a new MIB module will need to
   be created) in order to accommodate it.

7.3.4.  The Definitions of Managed Objects for IP Mobility
        Support using SMIv2 (RFC 2006)

   The problems are being resolved by the MIP6 WG [4].

7.3.5.  SMIv2 IP MIB (RFC 2011)

   This issue is being resolved by the IPv6 WG [5].

7.3.6.  SNMPv2 TCP MIB (RFC 2012)

   This issue is being resolved by the IPv6 WG [6].

7.3.7.  SNMPv2 UDP MIB (RFC 2013)

   This issue is being resolved by the IPv6 WG [7].

7.3.8.  RMON-II MIB (RFC 2021)

   This issue has been brought to the attention of the RMONMIB WG.
   Currently, there is a work in progress [8] to update RFC 2021, but it
   does not address the problems that have been identified; it is
   expected that there will be a resolution in a future version of that
   document.

7.3.9.  DataLink Switching using SMIv2 MIB (RFC 2024)

   The problems have not been addressed and an updated MIB should be
   defined.

7.3.10.  IP Forwarding Table MIB (RFC 2096)

   This issue is being worked on by the IPv6 WG [9].

7.3.11.  Classical IP & ARP over ATM MIB (RFC 2320)

   The current version of Classical IP and ARP over ATM (RFC 2225) does
   not support IPv6.  If and when that protocol specification is updated
   to add IPv6 support, then new MIB objects to represent IPv6 addresses
   will need to be added to this MIB module.
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容