Subject: [Int-area] [Fwd: Quick comments on draft-bonica-internet-icmp-00.txt]

From: Carlos Pignataro <[email-masked]>
Date: Thu, 19 Jan 2006 14:02:13 -0500

Posting to Int-Area on Ron's suggestion, to encourage discussion on this
I-D.

-------- Original Message --------
Subject: Quick comments on draft-bonica-internet-icmp-00.txt
Date: Tue, 17 Jan 2006 16:32:48 -0500
From: Carlos Pignataro <[email-masked]>
Organization: cisco Systems, Inc.
To: [email-masked], [email-masked], [email-masked],
       [email-masked]

Hello Ron, Der-Hwa, Pekka, Dan,

I was scanning through draft-bonica-internet-icmp-00.txt, and I noticed
a few quick things I wanted to comment on.

I hope this helps, I will be giving a complete (and more thorough) read
to the document and sending some more structured feedback if I come
across anything else.

1. Sections 5.1 through 5.4 define the location of the new `Length'
   field for the different ICMPs extended. In all four cases, the length
   is located at the low-order octet in the second word of the ICMP
   header. This however collides with the "packet too big" Destination
   Unreachange ICMP (3/4), where the low-order 16-bits in the second
   word are defined as the `NH MTU' (first defined in [RFC1191] IIRC).
   Granted, the extensions are mostly targeted (at least initially to
   allow extensions for traceroute) for using in TTL exceeded and other
   codes of Dest Unreach (port unreachable), but nonetheless the
   extensions should allow for extending any unreachable code.
   For an 8-bit Length field, if it is desired to define the Length
   field in the same position for all four ICMPs extended (which to me
   it should because it makes easier implementation), then the 2nd octet
   of the 2nd word is the only place available in all four ICMP Types.

2. Why is the Length field 8 bits? That would not allow for "Internet
   Header + leading octets of original datagram" larger than 256 octets,
   since the length field represents a value in octets, although
   [RFC1812] recommends including more than that (as much as possible so
   as for the entire ICMP to not exceed 576 octets). Shouldn't this
   Length field be 2 octets? Not sure how practical to include as much,
   but on the other hand it seems there's no reason to further restrict
   it.

3. Following on the same subject, Section 6.3 restrict the original
   datagram length of a "fully compliant app" to be no more than 128
   octets until there are no "partially compliant apps" out there. It
   would probably be practically impossible to determine when that
   happens. However, the draft that "partially compliant apps" are based
   upon allows for transporting octets above 128 of the embedded
   original datagram in the extended payload object (IIRC, or similar
   name); why not do the same here so as to allow for the "SHOULD
   contain as much as possible so that the complete datagram does not
   exceed 576 bytes" from RFC1812? With backward compatibility in mind,
   it's hard to see when/if the extension structure can start in any
   place other than byte 128.

4. There is a further constraint on the Length field: the draft reads
   that the Length attribute's value MUST be a multiple of four. That
   would not allow for cases where the embedded IP datagram length is
   not a multiple of four (i.e., what if the IP datagram TL is 47 octets
   or 99 octets?) Why this restriction? The way I understand it is that
   the Length field represents the Length of the embedded IP, and does
   not include the padding (it does not really represent where the
   extension structure begins, because of the zero-padding until 128
   octets.)

5. I noticed in the backwards compatibility section that it suggests a
   partially compliant application determines if extensions are present
   by examining the IP Total Length (164 octets). This assumes (I think
   incorrectly) that the IP HL is 20 bytes always (i.e., no options).
   Instead, it should count for example from the beginning of the ICMP
   header (i.e., 8 + 128 + 8 = 144) and not from the beginning of the
   datagram, since the IP Header can have options.

Thanks,

-- 
--Carlos.
Escalation RTP - cisco Systems

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area