[RFC] arp announce, arp_proxy and windows ip conflict verification

[RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

Windows (XP at least) hosts on boot, with configured static ip, performing 
address conflict detection, which is defined in RFC3927.
Here is quote of important information:

"
An ARP announcement is identical to the ARP Probe described above, 
except    that now the sender and target IP addresses are both set 
to the host's newly selected IPv4 address. 
"

But it same time this goes wrong with RFC5227.
"
The 'sender IP address' field MUST be set to all zeroes; this is to avoid
polluting ARP caches in other hosts on the same link in the case
where the address turns out to be already in use by another host.
"

When ARP proxy configured, it must not answer to both cases, because 
it is address conflict verification in any case. For Windows it is just 
causing to detect false "ip conflict". Already there is code for RFC5227, so 
just trivially we just check also if source ip == target ip.

Signed-off-by: Denys Fedoryshchenko <denys@visp.net.lb>
---

[-- Attachment #2: arp_announce.diff --]
[-- Type: text/x-diff, Size: 656 bytes --]

diff --git a/net-next-2.6/net/ipv4/arp.c b/linux-net-next-a/net/ipv4/arp.c
index 3f6b735..5afaf2a 100644
--- a/net-next-2.6/net/ipv4/arp.c
+++ b/linux-net-next-a/net/ipv4/arp.c
@@ -801,8 +801,11 @@ static int arp_process(struct sk_buff *skb)
  *  cache.
  */
 
-	/* Special case: IPv4 duplicate address detection packet (RFC2131) */
-	if (sip == 0) {
+	/* 
+	*  Special case: IPv4 duplicate address detection packet (RFC2131)
+	*  and Gratuitous ARP/ARP Announce. (RFC3927, Section 2.4) 
+	*/
+	if (sip == 0 || tip == sip) {
 		if (arp->ar_op == htons(ARPOP_REQUEST) &&
 		    inet_addr_type(net, tip) == RTN_LOCAL &&
 		    !arp_ignore(in_dev, sip, tip))

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[David Miller]

From: Denys Fedoryschenko <denys@visp.net.lb>
Date: Sun, 1 Mar 2009 13:44:45 +0200

> Windows (XP at least) hosts on boot, with configured static ip, performing 
> address conflict detection, which is defined in RFC3927.
> Here is quote of important information:
> 
> "
> An ARP announcement is identical to the ARP Probe described above, 
> except    that now the sender and target IP addresses are both set 
> to the host's newly selected IPv4 address. 
> "
> 
> But it same time this goes wrong with RFC5227.
> "
> The 'sender IP address' field MUST be set to all zeroes; this is to avoid
> polluting ARP caches in other hosts on the same link in the case
> where the address turns out to be already in use by another host.
> "
> 
> When ARP proxy configured, it must not answer to both cases, because 
> it is address conflict verification in any case. For Windows it is just 
> causing to detect false "ip conflict". Already there is code for RFC5227, so 
> just trivially we just check also if source ip == target ip.
> 
> Signed-off-by: Denys Fedoryshchenko <denys@visp.net.lb>

Patch applied to net-next-2.6

Although, It's a shame that I had to munge such a simple patch so
much, between the bad comment formatting and the trailing whitespace
characters.

Please be mindful of this in future patch submissions.

Thanks.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Wednesday 01 July 2009 01:55:59 Eric W. Biederman wrote:
>
> I have a problem with this patch.  It stops gratuitous arps updating
> my arp cache.  I'm still trying to figure out what the correct behaviour
> should be.
>
> Perhaps making the goto out; become if (sip == 0) goto out;
Yes, you are right. 

Proposing 3 simple patches against git next-next-2.6 . As attaches (sorry, 
kmail). All of them equal, but since i am amateur in programming, i dont know 
how it is should be done "nice way".

If you want to test it - do it carefully. I didn't did runtime tests yet, but 
they are compile tested. (But they are trivial).

If someone can review and tell if any of them ok, i will submit it with proper 
tags and etc.


[-- Attachment #2: patch1.diff --]
[-- Type: text/x-diff, Size: 694 bytes --]

diff -uprN net-next-2.6/net/ipv4/arp.c net-next-2.6.my/net/ipv4/arp.c
--- net-next-2.6/net/ipv4/arp.c	2009-07-01 01:00:58.000000000 +0300
+++ net-next-2.6.my/net/ipv4/arp.c	2009-07-01 01:24:19.000000000 +0300
@@ -811,11 +811,9 @@ static int arp_process(struct sk_buff *s
 		    !arp_ignore(in_dev, sip, tip))
 			arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha,
 				 dev->dev_addr, sha);
-		goto out;
-	}
-
-	if (arp->ar_op == htons(ARPOP_REQUEST) &&
-	    ip_route_input(skb, tip, sip, 0, dev) == 0) {
+		if (sip == 0) goto out;
+	} else if (arp->ar_op == htons(ARPOP_REQUEST) &&
+		    ip_route_input(skb, tip, sip, 0, dev) == 0) {
 
 		rt = skb_rtable(skb);
 		addr_type = rt->rt_type;

[-- Attachment #3: patch2.diff --]
[-- Type: text/x-diff, Size: 726 bytes --]

diff -uprN net-next-2.6/net/ipv4/arp.c net-next-2.6.my2/net/ipv4/arp.c
--- net-next-2.6/net/ipv4/arp.c	2009-07-01 01:00:58.000000000 +0300
+++ net-next-2.6.my2/net/ipv4/arp.c	2009-07-01 01:25:38.000000000 +0300
@@ -811,7 +811,10 @@ static int arp_process(struct sk_buff *s
 		    !arp_ignore(in_dev, sip, tip))
 			arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha,
 				 dev->dev_addr, sha);
-		goto out;
+		if (tip == sip)
+		    goto update;
+		else
+		    goto out;
 	}
 
 	if (arp->ar_op == htons(ARPOP_REQUEST) &&
@@ -858,6 +861,7 @@ static int arp_process(struct sk_buff *s
 
 	/* Update our ARP tables */
 
+update:
 	n = __neigh_lookup(&arp_tbl, &sip, dev, 0);
 
 	if (IPV4_DEVCONF_ALL(dev_net(dev), ARP_ACCEPT)) {

[-- Attachment #4: patch3.diff --]
[-- Type: text/x-diff, Size: 421 bytes --]

diff -uprN net-next-2.6/net/ipv4/arp.c net-next-2.6.my3/net/ipv4/arp.c
--- net-next-2.6/net/ipv4/arp.c	2009-07-01 01:00:58.000000000 +0300
+++ net-next-2.6.my3/net/ipv4/arp.c	2009-07-01 01:26:09.000000000 +0300
@@ -815,6 +815,7 @@ static int arp_process(struct sk_buff *s
 	}
 
 	if (arp->ar_op == htons(ARPOP_REQUEST) &&
+	    tip != sip &&
 	    ip_route_input(skb, tip, sip, 0, dev) == 0) {
 
 		rt = skb_rtable(skb);

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> Windows (XP at least) hosts on boot, with configured static ip, performing 
> address conflict detection, which is defined in RFC3927.
> Here is quote of important information:
>
> "
> An ARP announcement is identical to the ARP Probe described above, 
> except    that now the sender and target IP addresses are both set 
> to the host's newly selected IPv4 address. 
> "
>
> But it same time this goes wrong with RFC5227.
> "
> The 'sender IP address' field MUST be set to all zeroes; this is to avoid
> polluting ARP caches in other hosts on the same link in the case
> where the address turns out to be already in use by another host.
> "
>
> When ARP proxy configured, it must not answer to both cases, because 
> it is address conflict verification in any case. For Windows it is just 
> causing to detect false "ip conflict". Already there is code for RFC5227, so 
> just trivially we just check also if source ip == target ip.

I have a problem with this patch.  It stops gratuitous arps updating
my arp cache.  I'm still trying to figure out what the correct behaviour
should be.

Perhaps making the goto out; become if (sip == 0) goto out;

Eric



>
> Signed-off-by: Denys Fedoryshchenko <denys@visp.net.lb>
> ---
>
> diff --git a/net-next-2.6/net/ipv4/arp.c b/linux-net-next-a/net/ipv4/arp.c
> index 3f6b735..5afaf2a 100644
> --- a/net-next-2.6/net/ipv4/arp.c
> +++ b/linux-net-next-a/net/ipv4/arp.c
> @@ -801,8 +801,11 @@ static int arp_process(struct sk_buff *skb)
>   *  cache.
>   */
>  
> -	/* Special case: IPv4 duplicate address detection packet (RFC2131) */
> -	if (sip == 0) {
> +	/* 
> +	*  Special case: IPv4 duplicate address detection packet (RFC2131)
> +	*  and Gratuitous ARP/ARP Announce. (RFC3927, Section 2.4) 
> +	*/
> +	if (sip == 0 || tip == sip) {
>  		if (arp->ar_op == htons(ARPOP_REQUEST) &&
>  		    inet_addr_type(net, tip) == RTN_LOCAL &&
>  		    !arp_ignore(in_dev, sip, tip))

[PATCH] Revert "ipv4: arp announce, arp_proxy and windows ip conflict verification"

[Eric W. Biederman]

This reverts commit 73ce7b01b4496a5fbf9caf63033c874be692333f.

After discovering that we don't listen to gratuitious arps in 2.6.30
I tracked the failure down to this commit.

The patch makes absolutely no sense.  RFC2131 RFC3927 and RFC5227.
are all in agreement that an arp request with sip == 0 should be used
for the probe (to prevent learning) and an arp request with sip == tip
should be used for the gratitous announcement that people can learn
from.

It appears the author of the broken patch got those two cases confused
and modified the code to drop all gratuitous arp traffic.  Ouch!

Cc: stable@kernel.org
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
 net/ipv4/arp.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index f11931c..9c22032 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -801,11 +801,8 @@ static int arp_process(struct sk_buff *skb)
  *  cache.
  */
 
-	/*
-	 *  Special case: IPv4 duplicate address detection packet (RFC2131)
-	 *  and Gratuitous ARP/ARP Announce. (RFC3927, Section 2.4)
-	 */
-	if (sip == 0 || tip == sip) {
+	/* Special case: IPv4 duplicate address detection packet (RFC2131) */
+	if (sip == 0) {
 		if (arp->ar_op == htons(ARPOP_REQUEST) &&
 		    inet_addr_type(net, tip) == RTN_LOCAL &&
 		    !arp_ignore(in_dev, sip, tip))
-- 
1.6.0.6

Re: [PATCH] Revert "ipv4: arp announce, arp_proxy and windows ip conflict verification"

[David Miller]

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 30 Jun 2009 19:27:17 -0700

> This reverts commit 73ce7b01b4496a5fbf9caf63033c874be692333f.
> 
> After discovering that we don't listen to gratuitious arps in 2.6.30
> I tracked the failure down to this commit.
> 
> The patch makes absolutely no sense.  RFC2131 RFC3927 and RFC5227.
> are all in agreement that an arp request with sip == 0 should be used
> for the probe (to prevent learning) and an arp request with sip == tip
> should be used for the gratitous announcement that people can learn
> from.
> 
> It appears the author of the broken patch got those two cases confused
> and modified the code to drop all gratuitous arp traffic.  Ouch!
> 
> Cc: stable@kernel.org
> Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>

Applied and queued up for -stable, thanks Eric.

To be honest I didn't want to apply that patch, but it seemed
to match up with the RFC in question so I figured I had no
arguments against it :)

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Wednesday 01 July 2009 09:58:36 Eric W. Biederman wrote:
>
> What problem were you originally trying to solve?
>
> Having a proxy arp gateway reply to addresses it routes is proper
> behaviour.
>
> There are some aspects of RFC 5227 ipv4 address conflict detection that
> we could implement in a better fashion.  In particular the entirety
> of handling the pathological case of someone using one of our ip
> addresses in an arp message and replying to them to defend ourselves.
>
> Your changes seem aimed at having the linux kernel not reply to
> gratuitous arps, when according to our configuration the sender is
> misconfigured.  You seem to want linux not to defend itself in cases
> where it should.  Making us even less compliant with RFC 5227.
>
> Eric
It is still answering to gratuitous arp and handling the case!!!
But why patch was created, to NOT reply in case we have proxy_arp set, and we 
have default gateway. In this case, for example, Windows XP wont work at all 
in network where is Linux host with proxy_arp=1 installed. Because Linux will 
ALWAYS answer to arp requests.
Just only one case i miss (which is not defined in RFC by the way), that some 
software use this packet to update ARP tables on other hosts. And i sent 
patches for that. But imho they should use more legitimate ARP packets for 
that.

I did real testing even for my patch, and sure i sent patch only after that.

ip addr
.....
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1e:8c:89:78:af brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.21/29 brd 10.0.1.23 scope global eth0

I run windows vista (it sets correctly sip as 0.0.0.0)

home ipv4 # tcpdump -ni eth0
11:48:11.416790 ARP, Request who-has 10.0.1.21 tell 0.0.0.0, length 46
11:48:11.416797 ARP, Reply 10.0.1.21 is-at 00:1e:8c:89:78:af, length 28

2.6.30 vanilla (sure patch is there) handling case correctly.

The case i was trying to handle - proxy arp. Windows XP will be permanently 
disabled on reboot in case of proxy_arp enabled on Linux machine, and this 
Linux have default gateway (means answer to all proxy_arp).

This is XP (no conflict)
11:51:28.297633 ARP, Request who-has 10.0.0.5 tell 10.0.0.5, length 46
11:51:29.283672 ARP, Request who-has 10.0.0.5 tell 10.0.0.5, length 46
11:51:30.284210 ARP, Request who-has 10.0.0.5 tell 10.0.0.5, length 46

This is Linux 2.6.30 with patch applied, and Windows XP, handling correctly IP 
conflict.

11:53:10.440541 ARP, Request who-has 10.0.0.1 tell 10.0.0.1, length 46
11:53:10.440551 ARP, Reply 10.0.0.1 is-at b6:45:02:01:2b:b6, length 28
11:53:10.440796 ARP, Request who-has 10.0.0.1 tell 10.0.0.1, length 46
11:53:10.440799 ARP, Reply 10.0.0.1 is-at b6:45:02:01:2b:b6, length 28
11:53:10.466743 ARP, Request who-has 10.0.0.1 tell 10.0.0.1, length 46
11:53:10.466752 ARP, Reply 10.0.0.1 is-at b6:45:02:01:2b:b6, length 28
11:53:10.466976 ARP, Request who-has 10.0.0.1 tell 10.0.0.1, length 46
11:53:10.466979 ARP, Reply 10.0.0.1 is-at b6:45:02:01:2b:b6, length 28

So WITH patch ip conflict detection working.

And for sure it will work:

<------>if (sip == 0 || tip == sip) { // Yes, sip == tip
<------><------>if (arp->ar_op == htons(ARPOP_REQUEST) && // Yes it is request
<------><------>    inet_addr_type(net, tip) == RTN_LOCAL && // Yes this ip i 
have on my own host
<------><------>    !arp_ignore(in_dev, sip, tip)) // No i won't ignore this 
<------><------><------>arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha,
<------><------><------><------> dev->dev_addr, sha); // Send the host who 
sent gratuitous ip - that i am using it already.
<------><------>goto out;
<------>}

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Wednesday 01 July 2009 09:58:36 Eric W. Biederman wrote:
>
> What problem were you originally trying to solve?
>
> Having a proxy arp gateway reply to addresses it routes is proper
> behaviour.
It is not correct behavior to reply to gratuitous ARP, if you dont have this 
IP locally! 

IP conflict detection will fail then completely, if proxy arp machine have 
default route (means answer to ALL ARP requests). 

Sadly RFC 1027 (Proxy ARP) dated in 1987 and not explaining this case well.
I found other source of information, it is not reliable (wikipedia), but it is 
also mentioned in one of HP patents 
(http://www.freepatentsonline.com/y2009/0073990.html). My point of view 
marked as (!!!!!!!).

ARP announcements

An ARP announcement (also known as Gratuitous ARP) is a packet containing 
valid sender hardware and protocol addresses (SHA and SPA) for the host that 
sent it, with identical destination and source addresses (TPA = SPA). Such a 
request (!!!!!!!) is not intended to solicit a reply, but merely updates the 
ARP caches of other hosts that receive the packet. Gratuitous ARP is usually 
an ARP request [3], but it may also be an ARP reply [4].

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> On Wednesday 01 July 2009 09:58:36 Eric W. Biederman wrote:
>>
>> What problem were you originally trying to solve?
>>
>> Having a proxy arp gateway reply to addresses it routes is proper
>> behaviour.
> It is not correct behavior to reply to gratuitous ARP, if you dont have this 
> IP locally! 
>
> IP conflict detection will fail then completely, if proxy arp machine have 
> default route (means answer to ALL ARP requests). 

With proxy arp you pretend to have all of the IPs you are proxing for
locally.  You must do everything that the machine you are proxying for
would do on that network.

Having a default route and proxying everything is a misconfiguration.

> Sadly RFC 1027 (Proxy ARP) dated in 1987 and not explaining this case well.
> I found other source of information, it is not reliable (wikipedia), but it is 
> also mentioned in one of HP patents 
> (http://www.freepatentsonline.com/y2009/0073990.html). My point of view 
> marked as (!!!!!!!).
>
> ARP announcements
>
> An ARP announcement (also known as Gratuitous ARP) is a packet containing 
> valid sender hardware and protocol addresses (SHA and SPA) for the host that 
> sent it, with identical destination and source addresses (TPA = SPA). Such a 
> request (!!!!!!!) is not intended to solicit a reply, but merely updates the 
> ARP caches of other hosts that receive the packet. Gratuitous ARP is usually 
> an ARP request [3], but it may also be an ARP reply [4].

Of course a Gratuitous ARP is not intended to solicit a reply.  Because
two machines should not be configured to have the same IP address.

In the case of two machines being configured with the same IP address
replying to gratuitous ARP is correct behaviour.  As it allows discovery
of the network misconfiguration.

The problem is that you have a proxy machine configured to proxy for
the ip that is also assigned to another machine in the same broadcast
domain.  That is a bug.

The only case where I can imagine proxying the default route would even
approach being correct is on a point to point link.  But that seems
pointless as you could simply have a default route to the other side.

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote:
>
> Of course a Gratuitous ARP is not intended to solicit a reply.  Because
> two machines should not be configured to have the same IP address.
>
> In the case of two machines being configured with the same IP address
> replying to gratuitous ARP is correct behaviour.  As it allows discovery
> of the network misconfiguration.
Yes, and it is doing that with my patch also. It is answering if there is same 
_local address_, so it is definitely ip conflict. 

But Proxy ARP answering to ARP Announce without checking if destination 
address taken - wrong.  Because it should check if host in destination 
(proxied) network really is taken and should not answer if it is not. 

>
> The problem is that you have a proxy machine configured to proxy for
> the ip that is also assigned to another machine in the same broadcast
> domain.  That is a bug.
Where it is defined as bug? 
Sometimes it can be used on purpose, to filter traffic in local segment with 
lot of unmanaged switches.


>
> The only case where I can imagine proxying the default route would even
> approach being correct is on a point to point link.  But that seems
> pointless as you could simply have a default route to the other side.
Examples just came in mind:
1)Mobile IP. 

2)Port isolated setup, available on some switches and on wireless access 
points, when hosts cannot talk one to each other via broadcast domain, only 
via gateway. In this case gateway must give reply to legitimate arp requests, 
but ignore arp announce(gratuitous ARP).

I will search more respectable sources of information for this case. Btw it is 
difficult to find out this days "generic" gateway host without default 
gateway :-)

And last case, it breaks things for high availability ONLY because it doesn't 
update neighbor table. That can be fixed easily and i sent patches for that.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote:
> The only case where I can imagine proxying the default route would even
> approach being correct is on a point to point link.  But that seems
> pointless as you could simply have a default route to the other side.
>
> Eric

It seems Linux proxy_arp behavior is also RFC 1027 non-conformant.

Quote from RFC:

    In 4.3BSD (and probably in other operating systems), a default route
    is possible.  This default route specifies an address to forward a
!   packet to when no other route is found.  The default route must not
!   be used when checking for a route to the target host of an ARP
!   request.  If the default route were used, the check would always
    succeed.  But the host specified by the default route is unlikely to
    know about subnet routing (since it is usually an Internet gateway),
    and thus packets sent to it will probably be lost.  This special
    case in the routing lookup method is the only implementation change
    needed to the routing mechanism.



If i have linux host with 
eth0 10.0.0.1/24
eth1 10.0.1.1/24

sysctl -w net.ipv4.conf.eth1.proxy_arp=1

from other host in same ethernet segment eth1

Xpernet_137 ~ # arping -I eth1 2.4.6.8
ARPING to 2.4.6.8 from 1.0.0.1 via eth1
Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 501.685ms
Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 0.198ms

And RFC define to not do that (use default route for proxy_arp).

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote:
>> The only case where I can imagine proxying the default route would even
>> approach being correct is on a point to point link.  But that seems
>> pointless as you could simply have a default route to the other side.
>>
>> Eric
>
> It seems Linux proxy_arp behavior is also RFC 1027 non-conformant.
>
> Quote from RFC:
>
>     In 4.3BSD (and probably in other operating systems), a default route
>     is possible.  This default route specifies an address to forward a
> !   packet to when no other route is found.  The default route must not
> !   be used when checking for a route to the target host of an ARP
> !   request.  If the default route were used, the check would always
>     succeed.  But the host specified by the default route is unlikely to
>     know about subnet routing (since it is usually an Internet gateway),
>     and thus packets sent to it will probably be lost.  This special
>     case in the routing lookup method is the only implementation change
>     needed to the routing mechanism.
>
>
>
> If i have linux host with 
> eth0 10.0.0.1/24
> eth1 10.0.1.1/24
>
> sysctl -w net.ipv4.conf.eth1.proxy_arp=1
>
> from other host in same ethernet segment eth1
>
> Xpernet_137 ~ # arping -I eth1 2.4.6.8
> ARPING to 2.4.6.8 from 1.0.0.1 via eth1
> Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 501.685ms
> Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 0.198ms
>
> And RFC define to not do that (use default route for proxy_arp).

We agree that proxy_arp for the default route is problem behavior.

The question is can you configure proxy_arp to not do that in your
configuration?

There is the medium_id tunable and the per interface proxy_arp tunable.

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> On Wednesday 01 July 2009 20:40:08 Eric W. Biederman wrote:
>> The only case where I can imagine proxying the default route would even
>> approach being correct is on a point to point link.  But that seems
>> pointless as you could simply have a default route to the other side.
>>
>> Eric
>
> It seems Linux proxy_arp behavior is also RFC 1027 non-conformant.
>
> Quote from RFC:
>
>     In 4.3BSD (and probably in other operating systems), a default route
>     is possible.  This default route specifies an address to forward a
> !   packet to when no other route is found.  The default route must not
> !   be used when checking for a route to the target host of an ARP
> !   request.  If the default route were used, the check would always
>     succeed.  But the host specified by the default route is unlikely to
>     know about subnet routing (since it is usually an Internet gateway),
>     and thus packets sent to it will probably be lost.  This special
>     case in the routing lookup method is the only implementation change
>     needed to the routing mechanism.
>
>
>
> If i have linux host with 
> eth0 10.0.0.1/24
> eth1 10.0.1.1/24
>
> sysctl -w net.ipv4.conf.eth1.proxy_arp=1
>
> from other host in same ethernet segment eth1
>
> Xpernet_137 ~ # arping -I eth1 2.4.6.8
> ARPING to 2.4.6.8 from 1.0.0.1 via eth1
> Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 501.685ms
> Unicast reply from 2.4.6.8 [0:5:5d:2f:9b:ba] 0.198ms
>
> And RFC define to not do that (use default route for proxy_arp).

I just looked at the kernel code in a bit more detail as well as some examples.
With routing properly setup it appears largely fool proof.
The relevant piece in arp_process appears to be:

             if (addr_type == RTN_UNICAST  && rt->u.dst.dev != dev &&

Which says if when we consult the routing tables we would route the
packet out an interface that it did not come in by do the whole
proxy arp thing.

Which says to me you do not have a route to the machine which
is getting a address conflict on the network segment on which it
is located.

In summary the evidence I have suggests your routing is misconfigured.

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Thursday 02 July 2009 23:51:29 Eric W. Biederman wrote:
>
> I just looked at the kernel code in a bit more detail as well as some
> examples. With routing properly setup it appears largely fool proof.
> The relevant piece in arp_process appears to be:
>
>              if (addr_type == RTN_UNICAST  && rt->u.dst.dev != dev &&
>
> Which says if when we consult the routing tables we would route the
> packet out an interface that it did not come in by do the whole
> proxy arp thing.
>
> Which says to me you do not have a route to the machine which
> is getting a address conflict on the network segment on which it
> is located.
>
> In summary the evidence I have suggests your routing is misconfigured.
>
> Eric
It just have default route. Using it in proxy_arp clearly VIOLATE RFC!

I did small simulated setup.

Example:
default via 10.0.1.1 dev eth1
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.2
10.0.1.0/24 dev eth1  proto kernel  scope link  src 10.0.1.2

eth0 attached to my tap0

defaulthost ~ # sysctl -w net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.conf.eth0.proxy_arp = 1

Testing

home ~ # arping -I tap0 10.0.1.6
ARPING 10.0.1.6 from 10.0.0.1 tap0
Unicast reply from 10.0.1.6 [52:54:00:12:34:56]  85.706ms
Unicast reply from 10.0.1.6 [52:54:00:12:34:56]  0.683ms
^CSent 2 probes (1 broadcast(s))
Received 2 response(s)

!!! Correct. Thats why i need proxy_arp, i can reach hosts in eth1

home ~ # arping -I tap0 5.6.7.8
ARPING 5.6.7.8 from 10.0.0.1 tap0
Unicast reply from 5.6.7.8 [52:54:00:12:34:56]  353.697ms
Unicast reply from 5.6.7.8 [52:54:00:12:34:56]  0.740ms
Unicast reply from 5.6.7.8 [52:54:00:12:34:56]  0.697ms
^CSent 3 probes (1 broadcast(s))
Received 3 response(s)

!!! Not correct. It uses default route as reference "where i can route", which 
violates RFC.
Laptop with ip 5.6.7.8 (have nothing to do to with this router) with Windows 
XP will not be able to work. He will get ip conflict.
Network , for example, is on unmanaged switches, so i cannot isolate it from 
this router.

If i do:
defaulthost ~ # sysctl -w net.ipv4.conf.eth1.medium_id=2
net.ipv4.conf.eth1.medium_id = 2
defaulthost ~ # sysctl -w net.ipv4.conf.eth0.medium_id=2
net.ipv4.conf.eth0.medium_id = 2


home ~ # arping -I tap0 5.6.7.8
ARPING 5.6.7.8 from 10.0.0.1 tap0
^CSent 3 probes (3 broadcast(s))
Received 0 response(s)

Correct. Laptop will not get ip conflict

home ~ # arping -I tap0 10.0.1.6
ARPING 10.0.1.6 from 10.0.0.1 tap0
^CSent 3 probes (3 broadcast(s))
Received 0 response(s)

Not correct. Oops, i cannot talk with 10.0.1.6 anymore, and proxy_arp supposed 
to help me with this.

If i set different medium id - it will be same as default, 0. 
Any ideas how medium_id will help here?


So once more again, i dont mind proxy_arp main purprose to help devices to 
communicate in different physical networks. But if it gives answers to ARP 
announce it is WRONG. Because ARP answer for ARP announce(gratitous), it 
should only answer if it really knows about ip conflict. In current setup - 
if it have ip on this machine. 

ARP announce main puprose to update ARP cache AND to check for possible IP 
conflicts. proxy_arp current behavior will just screw this idea even without 
default issue.

If i have two networks proxy arp'ed
10.0.0.0/24 physical segment
10.0.1.0/24 physical segment

proxy_arp host between them, so users can set on their laptops /22 and 
communicate freely like they are in one segment.

Some user with XP on laptop with ip 10.0.0.66/22 will come to 10.0.1.0/24 
physical segment. As second he will turn on his laptop - proxy_arp host will 
give him incorrect answer to his ARP announce "10.0.0.66 (ff:ff:ff:ff:ff:ff) 
tell 10.0.0.66", it will tell "Reply 10.0.0.66 is-at 52:54:00:12:34:56" - 
that IP is busy. And thats wrong. arp_proxy should help hosts to communicate, 
but should not give incorrect answers that ip is taken.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> If i have two networks proxy arp'ed
> 10.0.0.0/24 physical segment
> 10.0.1.0/24 physical segment
>
> proxy_arp host between them, so users can set on their laptops /22 and 
> communicate freely like they are in one segment.
>
> Some user with XP on laptop with ip 10.0.0.66/22 will come to 10.0.1.0/24 
> physical segment. As second he will turn on his laptop - proxy_arp host will 
> give him incorrect answer to his ARP announce "10.0.0.66 (ff:ff:ff:ff:ff:ff) 
> tell 10.0.0.66", it will tell "Reply 10.0.0.66 is-at 52:54:00:12:34:56" - 
> that IP is busy. And thats wrong. arp_proxy should help hosts to communicate, 
> but should not give incorrect answers that ip is taken.

The problem is you have machines on the wrong subnet.

If you are not enforcing which network your laptops are in you
want ethernet bridging not proxy_arp.

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Friday 03 July 2009 01:18:33 Eric W. Biederman wrote:
>
> The problem is you have machines on the wrong subnet.
>
> If you are not enforcing which network your laptops are in you
> want ethernet bridging not proxy_arp.
>
> Eric
>
More important - feature must work CORRECTLY. Sometimes bridge is not fitting 
all needs. Probably behavior of well known networking vendor will be 
respected.

Here is example tested on Cisco IOS ( Cisco IOS Software, 7200 Software 
(C7200-ADVIPSERVICESK9-M), Version 12.4(4)T1, RELEASE SOFTWARE (fc4))


interface FastEthernet1/0
 ip address 10.0.1.2 255.255.255.0
 duplex half
!
interface FastEthernet2/0
 ip address 10.0.2.2 255.255.255.0
 duplex half
!
ip default-gateway 10.0.2.1


fa 1/0 - tap0
fa 2/0 - tap1

home ~ # arping -I tap0 10.0.1.5
ARPING 10.0.1.5 from 10.0.1.21 tap0
^CSent 3 probes (3 broadcast(s))
Received 0 response(s)
home ~ # arping -I tap0 10.0.2.5
ARPING 10.0.2.5 from 10.0.1.21 tap0
Unicast reply from 10.0.2.5 [CA:00:0A:FC:00:1C]  6.477ms
Unicast reply from 10.0.2.5 [CA:00:0A:FC:00:1C]  5.520ms
Unicast reply from 10.0.2.5 [CA:00:0A:FC:00:1C]  4.842ms
^CSent 3 probes (1 broadcast(s))
Received 3 response(s)
home ~ # arping -I tap0 4.5.6.7
ARPING 4.5.6.7 from 10.0.1.21 tap0
^CSent 4 probes (4 broadcast(s))
Received 0 response(s)

home ~ # ip addr add dev tap0 10.0.2.5
home ~ # arping -I tap0 10.0.2.5
ARPING 10.0.2.5 from 10.0.2.5 tap0

home ~ # tcpdump -ni tap0 -s 1500 -vvv
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 1500 
bytes
01:46:21.404454
01:46:31.404566
01:46:35.756623 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 
(ff:ff:ff:ff:ff:ff) tell 10.0.2.5, length 28
01:46:36.756740 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 
(ff:ff:ff:ff:ff:ff) tell 10.0.2.5, length 28
01:46:37.756821 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 
(ff:ff:ff:ff:ff:ff) tell 10.0.2.5, length 28

they dont answer btw also for ip's who is not in their network, but this 
doesn't matter, not defined in RFC, but good manner. Also it make impossible 
situation with ARP announce answered by Cisco and  will not make false 
positive IP conflict detection on Windows.

home ~ # tcpdump -ni tap0 -s 1500 -vvv
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 1500 
bytes
01:47:17.754393 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 
(ff:ff:ff:ff:ff:ff) tell 10.0.2.7, length 28
01:47:18.754581 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 
(ff:ff:ff:ff:ff:ff) tell 10.0.2.7, length 28
01:47:19.754628 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 
(ff:ff:ff:ff:ff:ff) tell 10.0.2.7, length 28
01:47:20.754674 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 
(ff:ff:ff:ff:ff:ff) tell 10.0.2.7, length 28


This is default behaviour,i just did 6 commands, no shutdown for interfaces, 
assign ip's, default gw and enable proxy arp on interfaces(btw seems they are 
enabled by default!), and it is CORRECT.

Conclusion:

1)Do not use default gateway for proxy-arp
2)Do not answer for ip's who doesn't belong to this interface (at least)

If i will put in network Linux machine, set default gw on other interface, and 
set proxy_arp - it will screw up whole network giving arp reply to all arp 
requests.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Friday 03 July 2009 01:18:33 Eric W. Biederman wrote:

and few more details

if i set 
"ip local-proxy-arp" on Fa 1/0

it still respects ARP Announce (as mypatch was doing, but mistake in patch it 
was not updating ARP cache)

home ~ # tcpdump -ni tap0 -vvv -s 1500
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 1500 
bytes
02:11:15.520588 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.8 
(ff:ff:ff:ff:ff:ff) tell 10.0.1.3, length 28
02:11:15.523696 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.1.8 is-at 
ca:00:0a:fc:00:1c, length 46
02:11:16.520616 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.8 
(ca:00:0a:fc:00:1c) tell 10.0.1.3, length 28
02:11:16.523365 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.1.8 is-at 
ca:00:0a:fc:00:1c, length 46
02:11:17.520635 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.8 
(ca:00:0a:fc:00:1c) tell 10.0.1.3, length 28
02:11:17.525146 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.1.8 is-at 
ca:00:0a:fc:00:1c, length 46
02:11:18.648310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.3 
(ff:ff:ff:ff:ff:ff) tell 10.0.1.3, length 28
02:11:19.648364 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.3 
(ff:ff:ff:ff:ff:ff) tell 10.0.1.3, length 28
02:11:20.648421 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.3 
(ff:ff:ff:ff:ff:ff) tell 10.0.1.3, length 28

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

What IOS is irrelevant to this discussion.
Especially when I don't see the "ip proxy-arp" command.

Having two networks:
10.0.0.0/24 physical segment
10.0.1.0/24 physical segment

It is correct for proxy arp to answer to for 10.0.0.66
when it is plugged into the 10.0.1.0/24 network.

Because in that case 10.0.0.66 is on the wrong subnet, and your
network is misconfigured.

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Friday 03 July 2009 02:23:09 Eric W. Biederman wrote:
> What IOS is irrelevant to this discussion.
Directly relevant, Cisco usually following standards very well.


> Especially when I don't see the "ip proxy-arp" command.
>From Cisco IOS manual:
ip proxy-arp

....

Defaults

Enabled 

It will show in config only "no ip proxy arp"

For example
show running 
....
interface FastEthernet2/0
 ip address 10.0.2.2 255.255.255.0
 duplex half
....

Router(config)#inter FastEthernet 2/0
Router(config-if)#no ip proxy-arp

show running

....
interface FastEthernet2/0
 ip address 10.0.2.2 255.255.255.0
 no ip proxy-arp
 duplex half
....

>
> Having two networks:
> 10.0.0.0/24 physical segment
> 10.0.1.0/24 physical segment
>
> It is correct for proxy arp to answer to for 10.0.0.66
> when it is plugged into the 10.0.1.0/24 network.
It is not defined in standart, correct or not. 

>
> Because in that case 10.0.0.66 is on the wrong subnet, and your
> network is misconfigured.
What Linux does care about this?
It is not police inspector to block me from taking this ip in wrong subnet.

And without emotions - it is not his job to give answers for wrong request 
(ARP Announce), from wrong ip (not linux with proxy arp enabled interface 
subnet). Especially because there is no use for current behavior, other than 
making problems.

And most important what you are telling violates RFC again, i finally found 
this in RFC 1027:

..."The gateway
    is acting as an agent for host B, which is why this technique is
    called "Proxy ARP"; we will refer to this as a transparent subnet
    gateway or ARP subnet gateway.
"...

"    An ARP subnet gateway implementation must not reply if the physical
    networks of the source and target of an ARP request are the same.
    In this case, either the target host is presumably either on the
    same physical network as the source host and can answer for itself,
    or the target host lies in the same direction from the gateway as
    does the source host, and an ARP reply from the would cause a loop.
"
Also not very clear, but maybe it is a reason why Cisco doesn't answer to ip 
who is not reachable from this interface
"
    If the IP networks of the source and target hosts of an ARP request
    are different, an ARP subnet gateway implementation should not
    reply.  This is to prevent the ARP subnet gateway from being used to
    reach foreign IP networks and thus possibly bypass security checks
    provided by IP gateways.
"



>
> Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[David Miller]

From: Denys Fedoryschenko <denys@visp.net.lb>
Date: Fri, 3 Jul 2009 02:03:08 +0300

> Probably behavior of well known networking vendor will be respected.

"cisco does it this way" used as the argument for how Linux should
behave will generally be treated as no argumentat all.

You have to give real technical reasons and so far Eric is the only
person providing that successfully.  Everything I've seen you argue so
far is pure vapor.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[David Miller]

From: Denys Fedoryschenko <denys@visp.net.lb>
Date: Fri, 3 Jul 2009 02:46:17 +0300

> On Friday 03 July 2009 02:23:09 Eric W. Biederman wrote:
>> What IOS is irrelevant to this discussion.
> Directly relevant, Cisco usually following standards very well.

No, IT IS TOTALLY FREAKIN IRRELEVANT!  And if you don't understand
that GO AWAY NOW.

If you, on the other hand, give a coherent and reasonable explanation
_WHY_ a certain behavior should be followed, that is convincing.  And
this is regardless of what Cisco does one way or the other.

Just like us, Cisco does stupid misguided shit too.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

>> Having two networks:
>> 10.0.0.0/24 physical segment
>> 10.0.1.0/24 physical segment
>>
>> It is correct for proxy arp to answer to for 10.0.0.66
>> when it is plugged into the 10.0.1.0/24 network.
> It is not defined in standart, correct or not. 
>
>>
>> Because in that case 10.0.0.66 is on the wrong subnet, and your
>> network is misconfigured.
> What Linux does care about this?
> It is not police inspector to block me from taking this ip in wrong subnet.
>
> And without emotions - it is not his job to give answers for wrong request 
> (ARP Announce), from wrong ip (not linux with proxy arp enabled interface 
> subnet). Especially because there is no use for current behavior, other than 
> making problems.

There is use. Talking to the machine that is known as 10.0.0.66 when
it is plugged into the network it is configured to be on.

> And most important what you are telling violates RFC again, i finally found 
> this in RFC 1027:
>
> ..."The gateway
>     is acting as an agent for host B, which is why this technique is
>     called "Proxy ARP"; we will refer to this as a transparent subnet
>     gateway or ARP subnet gateway.
> "...
>
> "    An ARP subnet gateway implementation must not reply if the physical
>     networks of the source and target of an ARP request are the same.
>     In this case, either the target host is presumably either on the
>     same physical network as the source host and can answer for itself,
>     or the target host lies in the same direction from the gateway as
>     does the source host, and an ARP reply from the would cause a loop.
> "

This is comedy.  They are supposed to be on different physical
networks as far as linux is configured.  The fact the laptop is in the
wrong place is something else again.

As for the rest.  I am not a great expert on how Cisco configuration
works.  In your example I believe you did not place the ports on
different vlans.  If both networks are run in the same vlan and
the packets will be bridged and everything will work smoothly.

Except when you explicitly configure it.  Linux does not do anything
layer 2.  So by default when we have two interfaces coming into a linux
box we do not bridge them.

Is this perhaps where you are confused?

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Friday 03 July 2009 06:14:44 Eric W. Biederman wrote:

Actually problem doesn't worth a broken egg even.
I am not confused. Just i am trying to explain that some feature 
implementation must follow standards somehow, especially because it break 
things. And it breaks. Actual use for proxy_arp in modern world is very small, 
and i think it is used rarely, only for PPP links for remote customers. But 
even in this case it will break things, if this box have default gateway.

1)If Linux have default gateway configured "some other" interface, enabling 
proxy_arp on ethernet interface will break communication for any network that 
is not configured on this Linux interface. It will just give ARP reply for 
all ARP requests.

2)ACD (Address conflict detection) used in DHCP, Mobile IP and etc, and it 
uses gratituous ARP/ARP Announce. 
Proxy ARP used to help route networks. 
Gratituous ARP/ARP Announce packet have no use for routing, it is for ACD and 
ARP cache updating (for clusters). Linux ARP proxy gives answer to such 
packets, which doesn't have use for routing, but breaks ACD (gives false 
positive ip conflict).

Anyway, i ask advice from one of RFC authors. I will forward it here as soon 
as receive it.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[David Miller]

From: Denys Fedoryschenko <denys@visp.net.lb>
Date: Fri, 3 Jul 2009 14:02:34 +0300

> Anyway, i ask advice from one of RFC authors. I will forward it here
> as soon as receive it.

Regardless of what this person says, I must bring up the most
important issue.

If we change this behvaior we have now, which has been present for
more than 10 years, we will break someone's setup potentially and that
must be considered strongly against all the other arguments.

I really never should have applied your initial patch, I severely
regret it.  Thanksfully it's reverted now and we can look into
this issue more properly.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Friday 03 July 2009 23:20:05 David Miller wrote:

> I really never should have applied your initial patch, I severely
> regret it.  Thanksfully it's reverted now and we can look into
> this issue more properly.
If it was said before...

Then maybe i will try to do some new sysctl value?

By default it will be old behavior, but it can be changed to new on user 
choice.

Let's say 

net.ipv4.arp_proxy_gateway 
net.ipv4.arp_proxy_gratuitous

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> On Friday 03 July 2009 23:20:05 David Miller wrote:
>
>> I really never should have applied your initial patch, I severely
>> regret it.  Thanksfully it's reverted now and we can look into
>> this issue more properly.
> If it was said before...
>
> Then maybe i will try to do some new sysctl value?
>
> By default it will be old behavior, but it can be changed to new on user 
> choice.
>
> Let's say 
>
> net.ipv4.arp_proxy_gateway 
> net.ipv4.arp_proxy_gratuitous

How do machines with addresses without routes to them
get packets from machines in other subnets?

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Saturday 04 July 2009 03:46:15 Eric W. Biederman wrote:
> Denys Fedoryschenko <denys@visp.net.lb> writes:
> > On Friday 03 July 2009 23:20:05 David Miller wrote:
> >> I really never should have applied your initial patch, I severely
> >> regret it.  Thanksfully it's reverted now and we can look into
> >> this issue more properly.
> >
> > If it was said before...
> >
> > Then maybe i will try to do some new sysctl value?
> >
> > By default it will be old behavior, but it can be changed to new on user
> > choice.
> >
> > Let's say
> >
> > net.ipv4.arp_proxy_gateway
> > net.ipv4.arp_proxy_gratuitous
>
> How do machines with addresses without routes to them
> get packets from machines in other subnets?
>
> Eric
ARP proxy generally was supposed to not export default route(by RFC and by 
logic) it should be maybe other name, arp_proxy_no_default_gateway_export - 
but i guess it is too long. With exporting default gateway i have two 
choices - eat it and have answer to almost any ARP request, or loose for 
proxy_arp completely this interface (by setting same medium id).

Btw usually proxy_arp "answers" only for directly attached networks, e.g. link 
layer routes (no gateway), but sure this is not a rule, and sometimes it is 
even useful to "proxy" gatewayed routes. I am concerned only about 0.0.0.0/0 
route, which is equal to wildcard.

If i understand question correctly.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> On Saturday 04 July 2009 03:46:15 Eric W. Biederman wrote:
>> Denys Fedoryschenko <denys@visp.net.lb> writes:
>> > On Friday 03 July 2009 23:20:05 David Miller wrote:
>> >> I really never should have applied your initial patch, I severely
>> >> regret it.  Thanksfully it's reverted now and we can look into
>> >> this issue more properly.
>> >
>> > If it was said before...
>> >
>> > Then maybe i will try to do some new sysctl value?
>> >
>> > By default it will be old behavior, but it can be changed to new on user
>> > choice.
>> >
>> > Let's say
>> >
>> > net.ipv4.arp_proxy_gateway
>> > net.ipv4.arp_proxy_gratuitous
>>
>> How do machines with addresses without routes to them
>> get packets from machines in other subnets?
>>
>> Eric
> ARP proxy generally was supposed to not export default route(by RFC and by 
> logic) it should be maybe other name, arp_proxy_no_default_gateway_export - 
> but i guess it is too long. With exporting default gateway i have two 
> choices - eat it and have answer to almost any ARP request, or loose for 
> proxy_arp completely this interface (by setting same medium id).
>
> Btw usually proxy_arp "answers" only for directly attached networks, e.g. link 
> layer routes (no gateway), but sure this is not a rule, and sometimes it is 
> even useful to "proxy" gatewayed routes. I am concerned only about 0.0.0.0/0 
> route, which is equal to wildcard.
>
> If i understand question correctly.

Problems occur when you have machines with ip addresses that you don't
have routes to.  How do machines with addresses without routes to them
get packets from machines in other subnets.

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Saturday 04 July 2009 18:00:58 Eric W. Biederman wrote:
>
> Problems occur when you have machines with ip addresses that you don't
> have routes to.  How do machines with addresses without routes to them
> get packets from machines in other subnets.
>
> Eric
They are not supposed to communicate then with this Linux host.
But Linux poisoning them by ARP replies.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> On Saturday 04 July 2009 18:00:58 Eric W. Biederman wrote:
>>
>> Problems occur when you have machines with ip addresses that you don't
>> have routes to.  How do machines with addresses without routes to them
>> get packets from machines in other subnets.
>>
>> Eric
> They are not supposed to communicate then with this Linux host.
> But Linux poisoning them by ARP replies.

How can that possibly be a correct network configuration?

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote:
>
> How can that possibly be a correct network configuration?
>
> Eric
It is a problem to have different networks, who doesn't communicate one with 
each other, in same ethernet segment?

Does it violate anything?

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Mark Smith]

On Sun, 5 Jul 2009 01:00:08 +0300
Denys Fedoryschenko <denys@visp.net.lb> wrote:

> On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote:
> >
> > How can that possibly be a correct network configuration?
> >
> > Eric
> It is a problem to have different networks, who doesn't communicate one with 
> each other, in same ethernet segment?
> 
> Does it violate anything?

I'm pretty sure it doesn't.

It's a common enough situation. A second subnet (or more) is assigned
to a link because the first isn't large enough, and renumbering the
hosts into a larger subnet is not practical at the time. A
'one-armed router' is used up stream to have traffic go between the
different subnets, at the cost of traffic double traversing the link.
(The worst example I've seen is 25 subnets operating this way!)

Fundamentally it is no different to routing traffic to other subnets.
IP was designed on the assumption that there'd only be a single subnet
per link, so nothing was done to make this scenario more efficent.

IPv6 has introduced the ability for hosts to be told by their default
router that destinations they think are "offlink", because the address
falls outside a locally assigned or learned prefixes, are actually
"onlink", preventing this double traversing problem.

Regards,
Mark.

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Denys Fedoryschenko <denys@visp.net.lb> writes:

> On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote:
>>
>> How can that possibly be a correct network configuration?
>>
>> Eric
> It is a problem to have different networks, who doesn't communicate one with 
> each other, in same ethernet segment?
>
> Does it violate anything?

The point of the internet protocol is communications between networks.

Setting up a router to route traffic in and off of a network and not
telling it about one of the networks on your ethernet segment is
at the least very peculiar.

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Eric W. Biederman]

Mark Smith <lk-netdev@lk-netdev.nosense.org> writes:

> On Sun, 5 Jul 2009 01:00:08 +0300
> Denys Fedoryschenko <denys@visp.net.lb> wrote:
>
>> On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote:
>> >
>> > How can that possibly be a correct network configuration?
>> >
>> > Eric
>> It is a problem to have different networks, who doesn't communicate one with 
>> each other, in same ethernet segment?
>> 
>> Does it violate anything?
>
> I'm pretty sure it doesn't.
>
> It's a common enough situation. A second subnet (or more) is assigned
> to a link because the first isn't large enough, and renumbering the
> hosts into a larger subnet is not practical at the time. A
> 'one-armed router' is used up stream to have traffic go between the
> different subnets, at the cost of traffic double traversing the link.
> (The worst example I've seen is 25 subnets operating this way!)
>
> Fundamentally it is no different to routing traffic to other subnets.
> IP was designed on the assumption that there'd only be a single subnet
> per link, so nothing was done to make this scenario more efficent.
>
> IPv6 has introduced the ability for hosts to be told by their default
> router that destinations they think are "offlink", because the address
> falls outside a locally assigned or learned prefixes, are actually
> "onlink", preventing this double traversing problem.

Multiple subnets on an ethernet segment sure.  Multiple subnets
subnets that don't communicate?  Not telling your router about all of
the subnets on the ethernet segment?

The combination of not configuring the router to know about all of the
subnets and enabling proxy arp is what is causing problems for Denys.

That sure seems like a misconfiguration to me.

Eric

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Denys Fedoryschenko]

On Sunday 05 July 2009 03:07:11 Eric W. Biederman wrote:
>
> Multiple subnets on an ethernet segment sure.  Multiple subnets
> subnets that don't communicate?  Not telling your router about all of
> the subnets on the ethernet segment?
>
> The combination of not configuring the router to know about all of the
> subnets and enabling proxy arp is what is causing problems for Denys.
>
> That sure seems like a misconfiguration to me.
>
> Eric
Real example

Still a lot of letters, but i hope it will help to understand situation.

Big office network. We trust each other and we dont have much money. So 
unmanaged switches. Network separated to two locations

Router in the middle.

eth0 - 10.0.0.2/24
eth1 - 10.0.1.1/24
default gateway is 10.0.0.1

arp_proxy enabled on both. Users have on machines netmask /22, so they can 
communicate freely. DHCP assigning addresses for them.

I just install few Windows XP machines in same network, and planned to do some 
tests only between them. I am just using same physical media, i dont think it 
is reasonable to install new switch and cables just for them. Sure if i had 
managed switches i can put them in separate VLAN, but it is just silly to do 
that, because proper network equipment will not interfere with this tests.
So i assign them ip's 192.168.1.1 , 192.168.1.2, 1.3, 1.4 and etc. No default 
gateway. I dont want my traffic go outside.

But whoops, on boot i got IP address conflict. Nice. Ok, let's say i manage 
it, it can be disabled in registry.

I am trying to do tests, and packets supposed to go from 192.168.1.1 to 
192.168.1.2 are being forwarded to router! WTF! In fact router by answering 
any ARP request, and is can be called "ARP spoofing", forwarding my packets 
to default gateway, and sure they wont come back. It makes difficult also to 
find problem, because ARP reply will be given by both hosts, legitimate and 
router who is violating RFC, and depends which come first and which last, it 
will work properly or not. Sure i can enable delay on sending proxy_arp 
request, but if windows host was down at this moment, it will give again, 
invalid "target" in MAC address.

On your logics i must reconfigure router each time when i do tests and assign 
some ip's. Actually i am bringing and plugging to network a lot of different 
equipment, with different default ips. I cannot plug them sometimes directly 
over crossover cable to my PC, and have to use network.

It doesn't look logic to reconfigure office router for each of those devices 
or to make isolation. Thats why in RFC mentioned " The default route must not
    be used when checking for a route to the target host of an ARP
    request. If the default route were used, the check would always
    succeed.  But the host specified by the default route is unlikely to
    know about subnet routing (since it is usually an Internet gateway),
    and thus packets sent to it will probably be lost."

Re: [RFC] arp announce, arp_proxy and windows ip conflict verification

[Mark Smith]

On Sat, 04 Jul 2009 17:07:11 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:

> Mark Smith <lk-netdev@lk-netdev.nosense.org> writes:
> 
> > On Sun, 5 Jul 2009 01:00:08 +0300
> > Denys Fedoryschenko <denys@visp.net.lb> wrote:
> >
> >> On Sunday 05 July 2009 00:57:32 Eric W. Biederman wrote:
> >> >
> >> > How can that possibly be a correct network configuration?
> >> >
> >> > Eric
> >> It is a problem to have different networks, who doesn't communicate one with 
> >> each other, in same ethernet segment?
> >> 
> >> Does it violate anything?
> >
> > I'm pretty sure it doesn't.
> >
> > It's a common enough situation. A second subnet (or more) is assigned
> > to a link because the first isn't large enough, and renumbering the
> > hosts into a larger subnet is not practical at the time. A
> > 'one-armed router' is used up stream to have traffic go between the
> > different subnets, at the cost of traffic double traversing the link.
> > (The worst example I've seen is 25 subnets operating this way!)
> >
> > Fundamentally it is no different to routing traffic to other subnets.
> > IP was designed on the assumption that there'd only be a single subnet
> > per link, so nothing was done to make this scenario more efficent.
> >
> > IPv6 has introduced the ability for hosts to be told by their default
> > router that destinations they think are "offlink", because the address
> > falls outside a locally assigned or learned prefixes, are actually
> > "onlink", preventing this double traversing problem.
> 
> Multiple subnets on an ethernet segment sure.  Multiple subnets
> subnets that don't communicate?  Not telling your router about all of
> the subnets on the ethernet segment?
> 
> The combination of not configuring the router to know about all of the
> subnets and enabling proxy arp is what is causing problems for Denys.
> 
> That sure seems like a misconfiguration to me.
> 

A misconfiguration if you don't intend it, otherwise, isolation between
subnets on a common link can be useful. I've taken advantage of it
in networking test labs. 

It can also be useful for basic traffic engineering. You set up two
routers attached to the same link, but both with different configured
prefixes. Nodes are assigned adresses out of one or the other prefix,
to influence which outbound (and inbound) path their traffic takes.
Leaving it like that would be a bit unusual, however it could be as
part of a gradual transition to splitting the link to reduce the
broadcast domain size.

Regards,
Mark.