Folks,
During a very pleasant telephone conversation, Joe Touch convinced me
that I am not so much _extending_ selected ICMP messages as
_redefining_ selected fields in those ICMP messages. At first glance,
the distinction between extension and redefinition might appear to be
inconsequential, but it is not.
If we were extending ICMP, future ICMP developers could write code that
is compliant with RFCs 792 and 1812, not specifying the length attribute
described in draft-bonica-internet-icmp. In fact, that
future programmer could be totally unaware of draft-bonica.
However, omission of the length attribute could cause compatibility
problems.
In order to maintain compatibility, when a future ICMP programmer codes
an ICMP message with the "original datagram" field greater than or equal
to 128 octets, that programmer MUST specify a length attribute.
So, in the next few days I will post an updated version of draft-bonica
that reflects Joe's comments. I realize that the word "redefinition"will
expose the draft to greater scrutiny, but I think that this is the right
thing to do.
Ron
Joe Touch wrote:
>
>
> Ron Bonica wrote:
>
>>>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.
>
>
> The issue is that the receiver doesn't check that the fields are zero;
> that makes sense from the sense of the original spec, but means that
> setting their value will not be checked by the existing implementations.
> This means that the payload that the option refers to CANNOT change
> based on those fields; it can be AUGMENTED (mean more), but the existing
> meaning (without length) cannot change. See below...
>
>
>>>>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.
>
>
> Dealing with one widely deployed base isn't the same as the issue of the
> current recommendations, as per 1812. This document appears to override
> that recommendation - that certainly needs to be more clear, at least.
>
> I would prefer wording that addresses the impact more specifically:
>
> IF this option is supported and used in a particular reply,
> the node MUST NOT send more than 128 bytes of the
> original packet. This overrides the reccomendation of RFC1812
> to include s much of the original packet as possible,
> up to a total of 567 bytes, and may affect the parsing of the
> packet contents in some cases.
>
> (this is alluded to, but not as specifically stated.
>
>
>>>>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?
>
>
> Sure. The trouble is that this is not backward compatible.
>
> Compliant existing implementations will ignore the length attribute, and
> then can (and should) interpret the entire payload as a prefix of the
> original segment.
>
> There is nothing they can do to know this is not the case. They can't
> check the IP checksum - the entire packet may not be included.
>
>
>>>That said, vendors would have two choices:
>>>
>>>- field fully compliant applications, understanding that TRACEROUTE
>>>would not be backwards compatibile with partially compliant ICMP
>>>implementations
>
>
> I don't understand how existing implementations that follow existing
> specs aren't fully compliant. This seems like an extension to ICMP; if
> you're overriding existing standards in a non-backward compatible way,
> that would be bad ;-)
>
>
>>>- field a partially compliant TRACEROUTE, possibly in addition to a
>>>fully compliant version of the same program.
>
>
> I don't know what the partially-complaint version refers to. I was
> thinking of two fully-compliant versions:
>
> - one that knows the existing codes
> - one that knows new codes with new meanings
>
> Joe
>
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
