[e2e] ICMP & TCP segments with IP ID = 0?

[Vernon Schryver]

> From: Alex Cannara <cannara at attglobal.net>

> Well, Vernon, I just love these emails.  {:o]
>
> By the way, why is x.25 always the straw man?  Are other arguments so
> weak?

No, my honest best guess for why Mr. Cannara has been for years so enthused
about counting packets instead of bytes and about the IP ID's is that he
first learned about network stuff by reading a trade rag description of
x.25.  We all have the most affection for our first systems, protocols,
and so forth, and to our personal detriment if they were not so obscure
and weird that we're not tempted to promote our first love as the end-all.
Replacing the TCP sequence number with a windowed packet ID like the IP
ID does not produce x.25, but it is a major step.


> Here's a partial delooping list over the last several years...
>
> Sniffer(r) used to discover complex hub miswiring causing looped IP pkts
> ...

> Sniffer(r) used to discover Cisco Cat5000 Spanning-Tree fault, looping
> ...

> Sniffer(r) located bridging loop in Federal agency's network that
> ...
>
> There are several more, but this is sufficient to demonstrate why the
> narrow view:  "the IP ID is not now and never has been either sufficient
> or necessary for anything that might be called loop resolution" is
> indeed narrow.

On the contrary, those three (3) instances have nothing to do with
anything that might be called loop resolution by hubs, switches, or
bridges that Mr. Cannara claimed as the justification for the IP ID
field.  They are also are fewer than the 5 I predicted would be the
limit of what Mr. Cannara could list as examples of a human figuring
out problems.  Moreover, there is no evidence that in those three cases
there was not plenty of other uniqueness in the looping packets that
would have been sufficient for other people to diagnose the problems.

Perhaps I misunderstood what Mr. Cannara meant when he spoke of loop
resolution.  I assumed he meant hardware and software using something
other than the TTL field, because he mentioned that the "TTL is only
decremented by routers, not hubs/switches/bridges."  If instead he
thinks that a 16-bit (or preferably larger) field should be maintained
in all packet headers merely for the entertainment of consultants who
cannot find other unique stigmata in packets displayed by one brand
of packet snooper, then all I can say is that I think I'll ask someone
else to define the next protocol I buy.


>                 I should add that problems like these are extremely
> expensive to companies when they occur, so assuming things are ok
> because some Linux boxes have avoided the intent, if not letter, of a
> sensible RFC is naive and inconsiderate of the real folks in real places
> that have to deal with products decendent from hubric network
> 'experts'.  The above problems all had existed for a week to a month,
> even jeopardized some large Cisco sales (we see how important that was
> :) and cost $250/hour + travel to fix.

Many of us have dealt with many packet loop problems in customer networks
over the decades.  Several years ago, about the time marketeers introduced
"switch" instead of "multi-port bridge" and espically "stupid multi-port
bridge without learning, spanning tree, or anything else you'd expect,"
packet looping problems were more common than they are now.  Most of us
do not find it necessary to rely on the IP ID field to figure out such
problems.  Some of us know that the ID field has not been a reliable
indicator for many years, and for that and other reasons look at more
than just the IP header when figuring things out.

The main problem of network hubris is not in the IETF, but among the
trade rag experts who, except for a few exceptions who prove the rule,
know little that is true and a lot that is false.  That would not be
a problem for the rest of us, except that the trade rag experts spend
so much effort distributing their special kind of wisdom.


Vernon Schryver    vjs at rhyolite.com