Subject: RFC 2576 vs IPv6

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 19 Feb 2003 12:50:11 -0800

Hi -

I think the analysis of RFC 2576 in section 5.070 (see below) of
draft-ietf-v6ops-ipv4survey-ops-00.txt is incorrect.
These rules for handling legacy data which happen to be
IPv4 addresses have no bearing on the ability to operate
in or manage IPv6 environments.

Randy

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

5.070 RFC 2576 Coexistence between Version 1 Version 2 and Version
      3 of the Internet-standard Network Management Framework (SNMP)

This document states:

   (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST
        be changed to IpAddress.  Note that the use of NetworkAddress in
        new MIB documents is strongly discouraged (in fact, new MIB
        documents should be written using SMIv2, which does not define
        NetworkAddress).

and defines the OID:

snmpTrapAddress OBJECT-TYPE
    SYNTAX      IpAddress
    MAX-ACCESS  accessible-for-notify
    STATUS      current
    DESCRIPTION
        "The value of the agent-addr field of a Trap PDU which
         is forwarded by a proxy forwarder application using
         an SNMP version other than SNMPv1.  The value of this
         object SHOULD contain the value of the agent-addr field
         from the original Trap PDU as generated by an SNMPv1
         agent."
    ::= { snmpCommunityMIBObjects 3 }

This clearly points out a lack of IPv6 awareness in this protocol.

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 19 Feb 2003 14:14:37 -0800 (PST)

> in or manage IPv6 environments.

I agree with that, and the same comment applies to the analysis of
the Notification Log MIB:

   5.112 RFC 3014 Notification Log MIB

   This document contains OIDs that are IPv4 specific:

   nlmLogVariableIpAddressVal OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
        "The value when nlmLogVariableType is 'ipAddress'.
        Although this seems to be unfriendly for IPv6, we
        have to recognize that there are a number of older
        MIBs that do contain an IPv4 format address, known
        as IpAddress.

        IPv6 addresses are represented using TAddress or
        InetAddress, and so the underlying datatype is
        OCTET STRING, and their value would be stored in
        the nlmLogVariableOctetStringVal column."
       ::= { nlmLogVariableEntry 9 }

   Not withstanding the note in the DESCRIPTION.

The purpose of this object is to handle legacy data.  It is, in
effect a member of a discriminated union designed to handle
arbitrary SMIv2 data types (including the obsolete ones), and its
presence in no way indicates that the MIB module is inadequate for
IPv6.

//cmh

---

From: "Philip J. Nesser II" <[email-masked]>
Date: Wed, 19 Feb 2003 14:16:30 -0800

Randy,

Thanks.  I will make updates in the -01 version.  The whole goal is
to solicit input from the people who have a much more intimate
knowledge of individual protocols than I do.  It has been a daunting
task and it is hard to fit everything together when you are trying to
digest 900 or so protocol documents.  I really appreciate your time
to read through the document and make your comments.

I am currently taking input from (hopefully) a lot of independent
sources and putting then all together.  

- --->  Phil

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Wednesday, February 19, 2003 12:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RFC 2576 vs IPv6
> 
> Hi -
>