ipid-debuggery (was Re: [e2e] ICMP & TCP segments with IP ID = 0?

[Kastenholz, Frank]

At 07:28 AM 5/17/01 -0400, Craig Partridge wrote:

>For instance, the reason that my query about the IP ID popped out was that
>we're tracing the path taken by IP datagrams by looking at the first 28 or
>so bytes of the packet.  If the IP ID is zero, it turns out that lots of
>packets for the same conversation look identifical trace their paths.  And
>if the IP ID is zero, you turn out to have lots of identical packets...

Gee, it sounds like you are doing the same thing that the
hypothetical ASIC designer did with his hypothetical packets
and his hypothetical ASIC :-)

>The interesting question is what status do such efforts have.  If they
>make use of a feature in the protocol that everyone is supposed to
>implement, and use that feature for a purpose beyond that which the
>protocol architects intended is that (a) wrong; (b) a second-class
>usage [e.g., they can't complain if people don't implement the feature]; or
>(c) a use of the protocol entitled to equal credence with work done before?

In the situation I described, we were in a test environment, so
coopting fields really had no external effect since we controlled
the entire environment so it really was out of scope.

That said, I do not see why using (or reusing/overloading) a
protocol feature is anything but "A use of the protocol entitled
to equal credence with work done before" -- as long as it doesn't
break anything that existed. Consider all the congestion work
that's been done over the past 15 years or so. From what I 
remember, back in the early days of TCP no one ever expected
to use TCP sequence numbers and packet-arrival events in the
way that we do now... 

We could get into, as Bob Braden called it, "mokishly over-
interpreting the sacred texts" here, but I see the sacred
texts as nothing more than guidelines. If we (the Internet
protocol community) were into monkishness and sacred texts,
then we'd have things like conformance suites and official
seals of approval for implementations. However, we are not
monks, etc, and our philosophy of protocol design and
development has been more along the lines of "as long
as it doesn't break anything..."

Frank Kastenholz