Subject: [Disman] RFC 2595: pingCtlDataSize

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 26 Mar 2003 10:45:29 -0800

Hi -

This is action item #10 from the minutes of our session in
San Francisco.

Currently, RFC 2925 says:
 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 }

This has caused some concern that the MIB isn't right for
IPv6.  As a technical contributor, I'd like to propose the
following as a clarification, and would selcome feedback,
especially from those who have implemented this in IPv6
environments:

    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 IPv4 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 for IPv4 environments.  If the protocol
        implied by the value of pingCtlTargetAddressType
        further limits the size of the data portion, the
        data is silently truncated to meet those constraints,
        without affecting the value reported by this object."

Again, since I haven't implemented this, I'd really welcome
feedback on this proposal from those who have.

Randy Presuhn