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

[Christian Huitema]

Also used by devices trying to correlate input and output of networks in
order to check delays, latencies, etc.

-----Original Message-----
From: Alex Cannara [mailto:cannara at attglobal.net] 
Sent: Thursday, May 17, 2001 12:04 PM
Cc: end2end-interest at postel.org
Subject: Re: [e2e] ICMP & TCP segments with IP ID = 0?

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

--