> 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.
Good catch! I will move the length field.
>
> 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.
True. If we were to make the length represent 32-bit words instead of
octets, this problem would be solved. In fact, 7 bits would be enough.
It would also remove the restriction that the length field be a multiple
of four.
>
> 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.
The restriction in Section 6.3 is probably a bit too severe. To the best
of my knowlege, the only partially compliant application is TRACEROUTE.
People wanting to trace through new routers shouldn't be too upset about
having to upgrade their TRACEROUTE application if they want to decode
new ICMP options sent from routers running new code.
>
> 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.)
The idea was to make the extension header start on a word boundary.
As I conceived it, the original datagram field would be zero-padded to
128 octets or the nearest word boundary, whichever is larger. The length
attribute reflects the length of the original datagram field (with
padding) and not neccessarily the length of the original IP datagram.
I will make this clearer in the draft.
>
> 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.
Good catch! This is an over-simplification. I will fix it in the draft.
Thanks for these comments.
Ron
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
