netdev
[Top] [All Lists]

per-route arp control

To: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Subject: per-route arp control
From: Julian Anastasov <ja@xxxxxx>
Date: Sun, 27 May 2001 23:41:59 +0000 (GMT)
Cc: "David S. Miller" <davem@xxxxxxxxxx>, <ak@xxxxxx>, <kuznet@xxxxxxxxxxxxx>, <netdev@xxxxxxxxxxx>
In-reply-to: <20010524175734.A23528@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
        Hello,

This is RFC - per-route ARP control for Linux 2.4 in two parts:

a) filtering ARP probes
b) selection of the source IP in the ARP probes

there are attached patches

1. Part one: filtering ARP probes

- semantic: "don't reply for input routes marked noarp"

- we add "noarp" flag for the "ip route" command

- we add "hidden" flag for the "ip addr add" command and this is
propagated to the created local route, i.e.

"ip addr add IP[/mask] ... hidden"
is converted to
"ip route add table local local IP[/mask] ... noarp

- we don't distinguish broadcast/unicast probes (skb->pkt_type), may
be this is useful in cases where we must block the unicast probes too.
Who relies on the unicast probes to continue to reply (as in
"hidden" for 2.2)? IMO, it can't fit into the NOARP semantic, we
must not reply. Alexey?

- only local and unicast routes are filtered, for example:

        a) local routes

        ip route add table local local 192.168.0.100 dev lo noarp

        b) unicast routes

        ip rule add prio 100 from 192.168.0.100 table 100
        ip route add table 100 default via 192.168.0.1 dev eth0 src 192.168.0.2 
noarp

Open question(s):

- the duplicate address detection code is not touched, do we need changes
there? As I see, ip_route_input can't be used.

The risks always exist if the "hidden" IP is used to talk IP to some
remote hosts that later will send probes and we will drop them with
noarp route but what routes are marked noarp is entirely under user
control.

2. Part two: source address selection for our probes

- semantic: "in our probes announce the preferred source address for
the target if the original route in the skb is marked noarp"

        Sometimes we don't want to announce particular addresses, for
example, if they are marked hidden/noarp in local routes - the symmetry.
In this case we add noarp route and then fallback to the preferred
source address no matter it is marked as hidden. The RTCF_NOARP flag
in the output routes is checked in this case (arp_solicit):

ip rule from ...
ip route add ... noarp

        Andrey, I see that in your current route.generic version
arp_solicit always fallbacks to the preferred source address to the
target, so the above 2nd part will disappear (it is a bit difficult to
use the above 2nd part from user space with ip route :( but it is easy
for kernel :) ).

The patches are attached:

noarp-2.4.5-1.diff - the kernel patch on top of Andrey's (and/or
        Alexey's?) arp patch but I added additional check for rt!=0
        in arp_solicit which disappeared after the first version

iproute2-noarp-1.diff - the supplementary patch for
        iproute2-2.2.4-now-ss001007.tar.gz

        I hope these ifdefs are the only way to compile iproute2 with
        kernels that don't support *HIDDEN and *NOARP defines. Or may
        be we can add the same functionality to 2.2?

The same patches will be here:

http://www.linuxvirtualserver.org/~julian/arp/

Comments?


Regards

--
Julian Anastasov <ja@xxxxxx>

Attachment: noarp-2.4.5-1.diff
Description: per-route arp control, patch against 2.4.5

Attachment: iproute2-noarp-1.diff
Description: iproute2 changes for per-route arp control

<Prev in Thread] Current Thread [Next in Thread>