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 PROTECTED]>
Organization: cisco Systems, Inc.
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
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 protected]
https://www1.ietf.org/mailman/listinfo/int-area
