RE: Running Ethernet without ARP

From: Robert White (rwhite_at_casabyte.com)
Date: 11/24/04

  • Next message: Adrian Bunk: "Re: [2.6 patch] small drivers/atm cleanups (fwd)"
    To: "'Karel Kulhavy'" <clock@twibright.com>, <linux-kernel@vger.kernel.org>
    Date:	Tue, 23 Nov 2004 18:57:44 -0800
    
    

    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/


  • Next message: Adrian Bunk: "Re: [2.6 patch] small drivers/atm cleanups (fwd)"

    Relevant Pages

    • RE: general sniffer question
      ... Subject: general sniffer question ... It is possible that what you saw was ARP broadcasts, ... communication protocol, they need the MAC address of each card, an ip ... > other peoples packets that are not broadcast packets. ...
      (Security-Basics)
    • Re: general sniffer question
      ... It is possible that what you saw was ARP broadcasts, ... communication protocol, they need the MAC address of each card, an ip ... > other peoples packets that are not broadcast packets. ...
      (Security-Basics)
    • Re: Translate MAC address to IP address
      ... >> every packet and counts traffic volume by source and destination MAC. ... with a bunch of gateway machines on it. ... results from the local ARP table. ...
      (freebsd-net)
    • RE: general sniffer question
      ... Subject: general sniffer question ... > It is possible that what you saw was ARP broadcasts, ... > communication protocol, they need the MAC address of each card, an ip ... >> other peoples packets that are not broadcast packets. ...
      (Security-Basics)
    • Re: Pure IP & ARP broadcasts
      ... It actually communicates via the MAC address of the Nics (aka Layer2 ... what the ARP request does. ... A host has a packet to send, it has the IP# and nothing else. ... But if the owner of the IP# is not on that segment then the Router replies ...
      (microsoft.public.windows.server.networking)