Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  IP Record Route in core?
Message-ID: <8702131254.a006197@Huey.UDEL.EDU>
Date: Fri, 13-Feb-87 12:54:20 EST
Article-I.D.: Huey.8702131254.a006197
Posted: Fri Feb 13 12:54:20 1987
Date-Received: Tue, 17-Feb-87 23:09:23 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 19
Approved: tcp-ip@sri-nic.arpa

Mike,

Yes, this is an old entry on my punch list: should an ICMP echo reply
recompute the route (fuzzball), go back the way it came (TOPS-20),
continue the route (?) or whatever. It may be time to reconsider
these issues carefully, since the recent congestion problems may well
be resolved using these tools. Onceuponatime I thought the cleverest
way to do this was to copy the inbound ICMP request into the data portion
of the requrst, then construct a new ICMP reply header, but only if the
request had a data portion large enough for the purpose. Then, Jerry
Saltzer at MIT beat me up, because he expected the data portions to
be returned unmodified. And so it goes.

Ahem, the fuzzies don't do the record route thing to spec anyway, since
they record the inbound address, not the return address of the outbound
packet. Finally, I thought the record route magic did in fact work for
the LSIways. At least the source route spells do.

Dave