RE: [2.4 PATCH] bugfix: ARP respond on all devices

David S. Miller wrote:

It means that systems (like Linux) that make IP addresses owned by the
host instead of specific interfaces cannot correctly interoperate with
such remote systems.

	This makes sense for replies, but not for requests.

	When a HOST sends out an ARP request, it's NOT associated with a
single connection, it's associated with the host. Why should it pick a
"random" IP number to send as the source address?

	The way the network code is currently, you're reducing your
connectivity to chance. There should be a defined process for making a
connection to another host. As it stands, this process is simply not
predictable.

	If you insist that an ARP request IS directly associated with a
connection, then you are required to have one ARP cache per source IP
address. It'd be predictable again ... but I don't think anyone wants to go
there.

It is also the case that a host cannot possibly be aware of all
subnets present on a given LAN, therefore is should be liberal in it's
replies to ARP requests.

	Well, actually, I know exactly which IP subnets are on which LAN
segments - they're defined by the IP address and subnet of the interface. I
think you'll find that this a pretty basic feature of most hosts.

Finally, it violates the most basic rule of IP networking:

"Be liberal in what you accept, and conservative in what you send"
-Jon Postel

	I'm sorry, but Linux simply isn't being conservative in what it
sends. It's being bloody awkward.

	Look at it this way - when a host sends out an ARP request, it WANTS
a reply, it's not doing it for fun. If it uses the IP number of the
interface it's sending the ARP request on, it will ALWAYS get a reply
(assuming there's one to get.) If it uses the IP number of another
interface, it MAY get a reply, but it MAY NOT.

	Are there any cases when this is reversed? I don't think so! Linux
is being intentionally difficult, and as far as I can tell, for no good
reason.

In general, when a host posses the information necessary to allow
other hosts to communicate, it should provide that information
whenever possible.

	No, it should follow the rules for letting traffic pass through it.
Just because a host can see two networks, doesn't mean it should route
between them - it possesses information, but there have to be rules to
determine how this information is used.

	Compare it to IP: If a firewall sees a packet come in on an
interface it shouldn't, it'll probably drop it - it's called anti-spoofing.
Should the firewall forward the packet on just because it can?

	So at the lower layer, a router sees an ARP packet with what looks
like a "spoofed" source address. Should it trust it implicitly and place it
in its cache, or should it drop it?

	No one yet has given one single example of a network that relies on
Linux's current behaviour. I've given two examples of networks that break
because of it. I would kindly suggest that the default should be changed.

	Thanks,

		Richard

On Tue, 19 Aug 2003 09:51:05 -0700
"David S. Miller" [off-list ref] wrote:

On Tue, 19 Aug 2003 17:54:26 +0100
Richard Underwood [off-list ref] wrote:

quoted

	When a HOST sends out an ARP request, it's NOT associated with a
single connection, it's associated with the host. Why should it pick a
"random" IP number to send as the source address?

It's not "random", it is using the IP address it intends
to use as the source in packets it will output once the
ARP completes.

In fact, if you look at the code in arp_solicit(), the source address
is coming directly from the packet we are trying to output.

Well, then you have a problem, at least with RFC-985 as quoted in my other
email.
If your host has two interfaces on two different pyhsical nets and host A from
net A shall be contacted by a service bound to your interface on net B you will
obviously send an arp request with a source ip from wrong subnet.
I did not read the code, I take your code explanation as true, of course.
It is very likely you will not receive a valid answer in this case:

<quote RFC-985>
An ARP request is discarded if the source IP address is not in the same subnet.
</quote>

Regards,
Stephan

On Tue, 19 Aug 2003 19:10:10 +0200
Stephan von Krawczynski [off-list ref] wrote:

Well, then you have a problem, at least with RFC-985 as quoted in my other
email.

RFC-985 does not take into consideration a system model where IP
addresses are owned by the host not specific interfaces which is a
valid system model that the RFC standards allow.

<quote RFC-985>
An ARP request is discarded if the source IP address is not in the same subnet.
</quote>

This RFC is broken in an environment consistent of systems using
the host address ownership model.

It also doesn't consider cases where the host receiving the
ARP request is not aware of all subnets present on a LAN.

Ignoring such ARPs is therefore broken and prevents valid
communications from occuring.

Some systems implement this check to provide "pseudo security",
but it isn't even that.

On Tue, 19 Aug 2003 17:54:26 +0100
Richard Underwood [off-list ref] wrote:

	When a HOST sends out an ARP request, it's NOT associated with a
single connection, it's associated with the host. Why should it pick a
"random" IP number to send as the source address?

It's not "random", it is using the IP address it intends
to use as the source in packets it will output once the
ARP completes.

In fact, if you look at the code in arp_solicit(), the source address
is coming directly from the packet we are trying to output.