On Thu, 3 May 2001, mouss wrote:
> There is however a problem on windows platforms.
> the ping program does not check the address in the response packet.
> more precisely, suppose you ping 1.2.3.4, and you receive a response
> from 10.0.0.1. the windows ping problem will say it is receiving a response
> from 1.2.3.4 instead of 10.0.0.1. It does not check the ICMP header!
> dunno what Linux does, but I'm certain it behaves as the BSD variant
> and reports that the response is from 10.0.0.1, which is the correct
> way.
While it may *seem* to be the correct way, rfc792 (Internet Control
Message Protocol) says of the source address:
[Quote]
Source Address
The address of the gateway or host that composes the ICMP message.
Unless otherwise noted, this can be any of a gateway's addresses.
[/Quote]
I can't find a single "otherwise noted" in the RFC, so if I'm misreading,
I'd appreciate a citation from anyone who's dug more deeply into it.
In host terms, packets should be source addressed from the interface
that's sending them. The recipient doesn't have any way to know what a
valid interface is on the target host, and therefore must either believe
anything that comes back, or only send control messages to the nearest
interface of the host (and hope it's not symetricly routed or multipathed.
[I have a long rant on control messaging being in band that I'll spare
everyone.]
This behaviour is correct from a compliant implemntation of ICMP, no
matter how braindead it seems on the surface. If you add things like
multi-meshed networks, especially with symetric routing, and null
interfaces and routing protocol networks, nearest-interface addressing
makes complete sense when the router is operating as a host, as it is as
the recipient and generator of control messages to one of its own
interfaces or in reply. We won't even talk about diagnostics when a
multihomed host sends spoofed packets from other interfaces on shared
layer 2 media where more than one interface is on the same segment and
you're trying to MAC address latch per-port on a switch.
I can go on for about a page on why things seem to need to work the way
they do to not complicate and slow down all processing on general hosts
(including routers when they're acting as layer 2 devices) if not outright
breaking some specific implementations if things were changed. That's
probably better done off-list if you're interested.
Thanks,
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]