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

[Dennis Ferguson]

> 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...
> 
> 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?

Here's a counter-example.  I wanted to make a router do something-in-IP
encapsulation (e.g. GRE, IP protocol 4, PIM-SM, IPv6 in IPv4) at very
high speed.  While I could always add hardware to do this perfectly,
that is expensive and I had a way to do this with no additional hardware
using processors already in the router's data path.  The problem is that
these processors, which are somewhat special-purpose and can keep up to
a very high speed data stream, are entirely stateless (almost all
operations in a router's forwarding path, at least where these processors
are, require no inter-packet state), so while I can build headers with
the processor, this particular operation wasn't envisaged when the
processor was designed and I had no way to come up with a unique value
for the IP ID.  Note that I'm sending non-fragmentable encapsulated
packets in any case since I'd prefer to fragment packets before they go
into the encapsulation tunnel as this keeps the decapsulating router at
the far end of the tunnel stateless as well.

So now we have an apples-to-apples cost comparison.  I'm cheaping out my
implementation of something by using the stateless hardware I have
rather than spending money to add stuff to keep the state.  You are
cheaping out your implementation by only looking at 28 bytes of packets,
rather than the 40 or more bytes and some additional complexity you'd
need to get a better packet signature from my packets.  Is it better
that I should pay to generate packets that make your application happy
(what I do seems to work fine other than this), or is it better that
you should pay to deal with my packets the way they are?

Note also that you are justifying your position by taking a prescriptive
interpretation of a single sentence in RFC 791, even though I think
many Internet standards (certainly including this one) stand up well against
time only because they are delightfully descriptive.  To add a sentence's
worth of context to your quote from the standard we have

    The identification field is used to distinguish the fragments of one
    datagram from those of another.  The originating protocol module of
    an internet datagram sets the identification field to a value that
    must be unique for that source-destination pair and protocol for the
    time the datagram will be active in the internet system.

This is clearly discussing fragmentation.  Is the second sentence
really a prescription for the setting of the IP ID field, with the
requirement being that it unconditionally needs to be set this way, or
is it actually just a plain-language description of how the IP ID field
needs to be maintained for the fragmentation and reassembly sub-protocol
to work, with the requirement being that the fragmentation and
reassembly sub-protocol needs to work?  I really think it is the latter,
and that it does no more good for you to point out that I am violating
the second sentence than it would for me to point out that you are
violating the first.

I think your application is good, I hadn't imagined someone would want
to use the field for anything other than is was defined to do (IPv6
doesn't seem to have imagined this either) but I can see how this would
be exceedingly useful.  I do something which didn't occur to anyone when
the processor which supports it was designed, but it works okay for me
anyway.  Ideally we both need to get our jobs done, and if we can't be
simultaneously happy now the best we can do is exchange data to keep
in mind so this can be fixed in future, one way or the other.

Dennis Ferguson