mike@BRL.ARPA.UUCP (02/12/87)
Phil Dykstra at BRL has just instrumented a version of my PING program for BSD UNIX to optionally issue the ICMP ECHO REQUEST packets with IP Record Route enabled. This has brought up several important issues: *) The core gateways do not record any route information, although they don't choke on the IP option. Is there any chance that they can be induced to store their address in the record route record, or is this another "wait for the Butterfly gateway" issue? In the BRL gateway, the IP Record Route code is about 20 lines of C... *) There is some ambiguity as to how to interpret the combination of ICMP ECHO REQUEST and IP Record Route together. The Mills Fuzzball software seems to regard the ICMP ECHO REPLY as a separate transaction, and resets the Record Route pointer to the beginning of the log area, while the BRL Gateway presently continues recording, so you see the full route, round trip. There is merit to both, is one considered "right"? *) 4.2 BSD UNIX, alas, can't handle the Record Route at all. *) 4.3 BSD UNIX answers, but strips off the Record Route when answering. (Actually, it strips all options except source routing). This is sub- optimal, and we will be working on a fix. *) Checksum fixes to the BRL Gateway IP Options code were needed too. If you want the code, (a) please wait a few weeks before asking, and (b) don't ask me, ask <Phil@BRL.ARPA>. Best, -Mike
brescia@CCV.BBN.COM.UUCP (02/12/87)
*) The core gateways do not record any route information,
This was a conscious design decision, not to look at any packets which do not
have the IP destination = 'the gateway'. Well, that's not the whole case,
because the lsi11 gateways will do IP header checksum and other validity
checks, but they will not examine the options unless fragmentation is needed.
The tradeoff was between speed and functionality. At that time, probably 4
years ago, we went for speed. At this time, the answer is, "wait for the next
generation". When faced with the same decision in the butterfly, I lost the
argument, so that will (does?) do record route, but at the expense (for
packets with record route option only) of extra processing at each hop,
because no shortcuts are taken past the full IP network routing.
Note that Source route does have a record route trailer.
In the BRL gateway, the IP Record Route code is about 20 lines of C...
I expect the 11 could do it with 40 lines of macn11 ... (but it would be wrong).
*) There is some ambiguity as to how to interpret the combination
of ICMP ECHO REQUEST and IP Record Route together. The Mills Fuzzball
software seems to regard the ICMP ECHO REPLY as a separate transaction,
and resets the Record Route pointer to the beginning of the log area,
while the BRL Gateway presently continues recording, so you see
the full route, round trip. There is merit to both, is one considered
"right"?
This could become an emotional issue of 'right vs. wrong' but I think that
more information is provided by NOT resetting the pointer. By the way, should
the echoing host also do a record route? Remember it's a host, not a gateway
function.
Mike B.Mills@UDEL.EDU.UUCP (02/13/87)
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