Re: [RFC] ip / ifconfig redesign

[Marc Singer <elf@buici.com>]

On Mon, Dec 05, 2005 at 11:48:52PM +0100, Jeroen Massar wrote:
> John Heffner wrote:
> > Jeroen Massar wrote:
> >> I wonder how many RFC's it violates. An interface must only answer ARP's
> >> on the interface that it is configured on, not anything else.
> > 
> > Not true.  See RFC 1122, section 3.3.4.  The standard leaves this
> > decision up to the implementation, for good reason.
> 
> RFC1122 is a document about multicast. ARP is broadcast see the very old
>  RFC826/STD0037. Multicast didn't even work on much of the hardware from
> the times that that document was written.
> 
> Probably the best text about this subject can be found in RFC1027:
> 8<-----------
> 2.4  Sanity checks
> 
>     Care must be taken by the network and gateway administrators to keep
>     the network masks the same on all the subnet gateway machines.  The
>     most common error is to set the network mask on a host without a
>     subnet implementation to include the subnet number.  This causes the
>     host to fail to attempt to send packets to hosts not on its local
>     subnet.  Adjusting its routing tables will not help, since it will
>     not know how to route to subnets.
> 
>     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.
> -------------->8
> 
> Which is almost the same as what I noted. Note that the document is
> about Proxy ARP, when a host is responding ARP queries for an IP on a
> different link, this is exactly what it is doing: proxy arp.

Interesting, but I don't think it applies.  We're talking about
reaching the node, not about using the node as a transparent gateway.
Note the part about "an ARP subnet gateway implementation" that need
to be careful.

> 
> > This topic has been discussed many times on a variety of mailing lists.
> >  I think the best way to do this is to make the behavior configurable,
> > which Linux currently does.
> 
> As long as the default is off I am fine with it, people turning it on
> themselves break their own network :)

Indeed.  Safety (sanity) first.