Hello Charles,
Yeah, I'm going to have to get the spell checker to look for valid RFCs as
well as words. :-)
I'd always assumed that the trace route utilities were utilizing the record
route option in IP and getting the path when they set TTL low enough to fail
at the last router. When TTL=0, somewhere in the network, the device
holding the packet would send an ICMP time exceeded message back to the
source. This is described in Request For Comment seven hundred ninety-two
:-). While it's creating this new packet, it takes the header of the
destroyed IP packet and dumps it into the payload of the ICMP packet.
>From the RFC:
Internet Header + 64 bits of Data Datagram
The internet header plus the first 64 bits of the original
datagram's data. This data is used by the host to match ...
As the original packet goes through the NAT towards the destination, the NAT
will modify the source and destination addresses but it probably can't
figure out what to do with the recorded route portion. The "internal"
routers will continue to add their addresses to the header until TTL is
exceeded. Then, when the ICMP packet is going back "outside", the NAT will
again translate the source and destination but won't dig into the ICMP
packet to modify the traced route portion of the embedded IP header.
RFC-One thousand six hundred thirty-one gets a little hazy when it talks
about address translation of ICMP packets through the NAT.
It is not entirely clear if the IP header information in the ICMP
part of the body really need to be modified. This depends on whether
or not any host code actually looks at this IP header information.
Indeed, it may be useful to provide the exact header seen by the
router or host that issued the ICMP message to aid in debugging. In
any event, no modifications are needed for the Echo and Timestamp
messages, and NAT should never need to handle a Redirect message.
SNMP messages could be modified, but it is even more dubious than for
ICMP messages that it will be necessary.
Is there anyone that would care to comment about how trace route programs
actually work?
Thanks,
Chris Lonvick
Cisco Systems
Consulting Engineering
+1-713-778-5663
At 11:25 PM 9/8/96 -0500, Charles Ragan wrote:
>Chris,
>
>Thanks for the heads up and info! You mis-typed rfc 792 (729 is the IAC for
>telnet ;-)
>
>So....let me see if I have this straight (since I've only digested it!) -
--remainder deleted for brevity--
|
|
