Joe Touch wrote:
> I raised a few on the INT-AREA mailing list in Oct 2005 in the
> pre-ICMP/MPLS split which were not addressed in either the 00 or 01
> versions of this draft.
>
> ---
> Use of the "unused" area, as Ron suggested, seems inappropriate because
> those fields are not known to be 'cleared' by existing ICMP sources, so
> their value cannot be reliably used for flags IMO.
> ---
Joe,
RFC 792 compliant implementations clear all unused bits. The statement
below is from RFC 792:
"Any field labeled "unused" is reserved for later extensions and must be
zero when sent, but receivers should not use these fields (except to
include them in the checksum)."
The rest of the argument hinges upon us being able to trust that a
non-zero value in the length field really represents the length of the
original-datagram field. If we can't agree on that much, the rest of the
argument is moot.
>
> A few further concerns are below:
>
> The technique of using a valid checksum to "correctly determine" that
> the option is present at the 137th byte is overstated. The 1's
> complement checksum can be used to infer that data has not been
> corrupted, but it is not appropriate for data synchronization (the use
> here), as would, e.g., a stronger sum such as a CRC. 1's complement is
> known to be susceptible to packet corruption that dovetails portions of
> packets together (see Stone and Partridge, Sigcomm 2000).
>
I reluctantly agree...
If the checksum is not correct, the application determines that the
subsequent bytes do not represent valid extensions. However, if the
checksum is correct, the application is not 100% certain that the
subsequent bytes represent valid extensions. It is certain only to some
level of probability.
However, I think that there is a way to work around this. See my final
comment, below.
> Finally, and most importantly, the document does not sufficiently
> address how it will affect the payload of ICMP packets, in changing
> existing Internet recommendations. When the payload of certain messages
> is smaller than 128 bytes, it will work fine. However, section 6
> suggests (somewhat obscurely) that future implementations send only 128
> bytes to represent the datagram. This is in direct opposition to the
> recommendations of RFC 1812.
We could back off from that suggestion.
The only reason that we make it is because a widely deployed base of
partially compliant TRACEROUTE applications relies on the original
datagram field containing exactly 128 octets. However, this is not a
hard requirement. If an ICMP implementation doesn't need to be backwards
compatible with those partially compliant TRACEROUTE applications, it
could send more octets.
>
> The only solution to these issues appears to be the creation of new type
> codes and the emission of two errors for each ICMP error - one under the
> current code, one with the new, augumented code. Short of this, it is
> unclear that a backward compatible extension such as this can usefully
> coexist.
Do you think that the proposal could be salvaged by saying that a fully
compliant application MUST NOT parse for extentions unless a length
attribute is specified? That said, vendors would have two choices:
- field fully compliant applications, understanding that TRACEROUTE
would not be backwards compatibile with partially compliant ICMP
implementations
- field a partially compliant TRACEROUTE, possibly in addition to a
fully compliant version of the same program.
Ron
>
> Joe
>
> Ron Bonica wrote:
>
>>>None that have been brought to my attention.
>>>
>>> -ron
>>>
>>>Margaret Wasserman wrote:
>>>
>>>
>>>>Thanks, Ron!
>>>>
>>>>Are there any remaining concerns about this document that should be resolved
>>>>before I agree to sponsor it for publication (which will include sending it
>>>>for a 4-week IETF LC)?
>>>>
>>>>Margaret
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [EMAIL PROTECTED]
>>>>>[mailto:[EMAIL PROTECTED] On Behalf Of Ron Bonica
>>>>>Sent: Monday, January 30, 2006 9:40 AM
>>>>>To: [EMAIL PROTECTED]
>>>>>Subject: [Int-area] draft-bonica-internet-icmp
>>>>>
>>>>>Folks,
>>>>>
>>>>>I have updated draft-bonica-internet-icmp. The new version
>>>>>can be found at the following URL:
>>>>>
>>>>>http://www.ietf.org/internet-drafts/draft-bonica-internet-icmp-01.txt
>>>>>
>>>>>The most significant change is that the "length" field has
>>>>>been moved to avoid a conflict with the "Next-Hop MTU" field
>>>>>that is defined in RFC 1191.
>>>>>
>>>>> Ron
>>>>>
>>>>>_______________________________________________
>>>>>Int-area mailing list
>>>>>[email protected]
>>>>>https://www1.ietf.org/mailman/listinfo/int-area
>>>>>
>>>>
>>>>
>>>_______________________________________________
>>>Int-area mailing list
>>>[email protected]
>>>https://www1.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
