Subject: Re: RFC 2925 (disman remote operations) Implementation Experience

From: Randy Presuhn <[email-masked]>
Date: Thu, 1 Nov 2001 14:51:31 -0800 (PST)

Hi -

One bit of feedback on the remote operations MIB...

In <draft-ietf-ngtrans-ipv4survey-01.txt> "Survey of IPv4
Addresses in Currently Deployed IETF Standards", it is written:

|5.516 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 thought.  In the following OIDs:
|
| 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 }
|
|There is clearly an assumption of IPv4 header sizes.

What do we need to do to satisfy the IPv6 folk?

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Nov 2001 11:34:18 +0100

>>>>> Randy Presuhn writes:

Randy> In <draft-ietf-ngtrans-ipv4survey-01.txt> "Survey of IPv4
Randy> Addresses in Currently Deployed IETF Standards", it is written:

[...]

Randy> What do we need to do to satisfy the IPv6 folk?

The text in question gives a reasoning for the upper size limit.  An
IPv6 header is at least 40 bytes (if I understand RFC 2460 correctly).
So far we are fine. But wait:

The IPv4 header contains a "total length" field which is 16 bit while
the IPv6 header contains a "payload length" field which is 16 bit. RFC
2460 says:

   Payload Length       16-bit unsigned integer.  Length of the IPv6
                        payload, i.e., the rest of the packet following
                        this IPv6 header, in octets.  (Note that any
                        extension headers [section 4] present are
                        considered part of the payload, i.e., included
                        in the length count.)

So the IPv6 header is not really included and it might be possible to
IPv6 packets which have 65535 octets in the payload. If this is
indeedt true, then the upper size should actually be 65535 minus the
UDP header size for the two objects.

The other option would be to just use 65535 as the upper bound and to
say in the DESCRIPTION how implementations should react if they do not
support a given size. This gets us out of the byte counting trouble
and I guess that some implementations will have their own constraints
and not support the full theoretical range anyway.

/js