lkml.org 
[lkml]   [2004]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Running Ethernet without ARP
Date
Howdy,

Skipping the question of _why_ you would want to do this for a moment.

_IF_ you connect two and only two devices, then each machine can use the "anything I
didn't send is for me" metric and you can send hand-crafted packets to the hardware
(MAC) broadcast address. This is the overly-short version of how things like the arp
request works in the first place. "All the other adapters" will get the packet and
process it. [In the case of ARP, only the machine owning the IP address responds, so
we all learn the IP/MAC address binding.]

If you intend this link to carry IP packets then you'll have to see to making sure
that all the IP stuff still works out right. If not, the "optimization" of removing
ARP will just lead to more CPU load (or something) while the nonsensical IP headers
are processed for the bad packets. Again you could use the IP broadcast address and
the "I didn't send it, so it's for me" logic.

To some extent, doing the IP broadcasting makes the ARP stuff factor out "for free"
in that you don't ever have to ARP request/respond when using the (sub)net broadcast
address for the "locally attached" network segment.

So that gets you back to what you require/mean by the link "working". If you have
intimate control over the exact nature of the data being transmitted (e.g. this isn't
a general IP service/router experience) then you can do all sorts of stuff to meet
highly specialized designs. [e.g. I have worked "component based" measuring
equipment that linked the components via Ethernet chipsets/hardware but didn't do
anything remotely like IP.] In the routing case you cannot (usefully) rewrite the IP
header without building a point-to-point tunnel between the two machines, which would
cost you more than ARPing anyway.

So that also begs the question of why ARP is so undesirable? It isn't that expensive
and without hand-coded MAC address limiting peer tables, it is no more/less secure
than the wire anyway.

The short version is that there is no "free or nearly free" way to do this for a
_generalized_ application. You would be looking at a lot of work. For very specific
applications (from-scratch work) you may be able to coerce your design into a simple
pattern like IP or MAC broadcasting.

The link-without-ARP requirement (with no access to one machine and blind
interoperability) sounds an awful lot like some of the odd requirements for
not-secure-to-secure network bridging from some of the government contracts I've run
across. If you are trying to do the whole no-round-trip bridge [e.g. "provable"
one-way, fiber link with only one connector, blind transfer, public-to-secure bridge]
stuff for a particular set of data or protocols (SNMP Trap promotion being a big
perennial culprit for government monitoring at security boundaries 8-) put the/a
receiver endpoint/processor on the public machine, wrap the *entire* packet into
MAC-level broadcast packet (e.g. your own one-sided broadcast protocol) and assert it
on the one-way adapter using the raw packet interface. At the secure end, crack
"your" protocol packets, do the security cooking as necessary (rewrite the trap
source etc), and then forward the resulting packet like it were normal. (been there,
done that, /sigh)

That was a lot of guessing, but hope that helps.

Rob White,
Casabyte, Inc.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]
On Behalf Of Karel Kulhavy
man netdevice says:
"IFF_NOARP No arp protocol, L2 deswtination address not set".
Is it possible to run ptp Ethernet link between two Linux routers this
way? I would like to run the link with two constraints:
1) no ARP protocol used
2) The link should continue to work even if root access to one computer is
inaccessible and the NIC in the other one is replaced without changing it's MAC
(for example because it doesn't support MAC change)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:1.097 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site