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

[Alex Cannara]

Well, Vernon, I just love these emails.  {:o]

By the way, why is x.25 always the straw man?  Are other arguments so
weak?

Here's a partial delooping list over the last several years...

Sniffer(r) used to discover complex hub miswiring causing looped IP pkts
from Sun host -- Johnson & Johnson (a small company :).

Sniffer(r) used to discover Cisco Cat5000 Spanning-Tree fault, looping
IP pkts among hospital hubs @100Mb/s -- Columbia S.C. (nurses unable to
access patient data -- no casualties except Cisco support :).

Sniffer(r) located bridging loop in Federal agency's network that
extended from Wash D.C. to Cincinnatti (admin who connected mystery
bridge demoted a G level :).

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

Alex



Vernon Schryver wrote:
> 
> > From: Alex Cannara <cannara at attglobal.net>
> 
> > TTL is only decremented by routers, not hubs/switches/bridges.  This
> > succinct but ineffective comment illustrates the narrow view.
> 
> > > > This is a narrow view.  Since IP is not LAN aware, it's a good feature
> > > > to have a unique identifier in any network-layer stream to allow loop
> > > > resolution, which is otherwise difficult.
> > >
> > > TTL.
> 
> More important than the breadth of one's view is it's consistency with
> reality.  A sufficiently broad view is useless because it is incapable of
> distinguishing black from white or x.25 from TCP/IP.
> 
> Please name a single real piece of equipment or software that has ever
> used the IP ID field for anything might reasonably be called loop
> resolution in production (i.e. none of the wild and crazy things done
> in lab smoke-testing of software and hardware, including ASIC's).  Feel
> free to name more than 5 instances where the IP ID was used manually while
> staring at packet traces to diagnose broken bridges or other loops.
> 
> Of course, it is impossible to name such hardware or software that has
> been used on the Internet or major corporate networks at least within the
> last 10 or 15 years, because the IP ID is not now and never has been either
> sufficient or necessary for anything that might be called loop resolution.
> This is proven by many facts, including the bazillions of Linux boxes now
> on the Internet that are using evil, nasty, cheating, evil, and unjustified
> constant-0 ID's but nevertheless working just fine.
> 
> Moreover, hubs, switches, and bridges that do not use the IP TTL field
> are even less likely to notice (not to mention use) the IP ID field.  In
> theory they might, but such a theory would require them to keep and compute
> with far more state than is even slightly plausible except in toy
> situations that don't need anything that might be called loop resolution.
> Sheesh!--how is a hub, switch or bridge supposed to use a packet ID field
> to detect loops except by noticing when it sees a single ID too many times,
> and how could it do that except in a marketeer's cloud diagram?
> 
> Insisting on not putting a reasonably distinguishing value in the IP ID
> field such as with an equivalent of "field=++cnt" for mere ideological
> reasons is bad, but not as bad as insisting that the ID field can, is,
> will be, or ever has been used for things that it hasn't, can't, and won't
> ever be used for.
> 
> In yet other words, TCP/IP counts bytes instead of packets for several
> reasons starting with the fact that TCP/IP is not x.25, and neither of
> those facts is a bug or a mistake in TCP/IP or x.25.  It is not a broad
> but an extremely narrow view that cannot see any good in the differences
> between x.25 and TCP/IP.
> 
> Vernon Schryver    vjs at rhyolite.com

--