In the case only hubs are used to connect devices do we need ARP?

Packets will be forwarded to every device. So, when a packet whose destination IP doest does not match with the device IP, it will be discarded.

In such a scenario I believe that it is not efficient to generate ARP traffic.

Am I missing something?

  • You're layer 3 device won't send the traffic onto the wire if it doesn't have an entry in the ARP table. I guess in theory you could create static ARP entries for every single IP address, all associated with MAC FFFF.FFFF.FFFF
    – John K.
    Jan 25, 2017 at 15:29
  • 1
    Exactly. Tha's what I meant. By using layer 2 broadcast address FFFF.FFFF.FFFF as a destination for every sent frame, I think that we can avoid the generation of ARP traffic in such scenario. Can it work theoretically?
    – gaetano
    Jan 25, 2017 at 15:32

5 Answers 5


The destination MAC address serves three functions.

  1. It allows switches to limit the distribution of the frame.
  2. It allows network cards to filter out unwanted frames in hardware.
  3. It ensures unicast frames are received and processed by exactly one host/router, preventing packet duplication.

I am sure you could hack up a TCP/IP stack to remove arp and use a single MAC address for everything and you could make it work on a local network with only hubs and no switches or routers. Why anyone would want to do such a think I have no idea.

  • Can this work without hacking TCP/IP stack, by using layer 2 broadcast address as a destination for every sent frame? This is just a theoretical question, I am not interested in implementing such a thing :-)
    – gaetano
    Jan 25, 2017 at 14:02
  • @user, if you broadcast everything, every host must be interrupted and inspect broadcast frames to see if the frames are for them, but a host will ignore any frames not addressed with its MAC address. What you propose would be inefficient when it comes to host resources. You could use broadcast for every frame on a switched network, too, with the same result.
    – Ron Maupin
    Jan 25, 2017 at 15:46
  • 2
    Indeed this is inefficient. A NIC can do MAC address check in hardware. IP address check is made in software and takes more time. Thanks @RonMaupin
    – gaetano
    Jan 25, 2017 at 15:55
  • @user, ARP is actually pretty efficient. Each host maintains an ARP cache, so once it learns the layer-2 to layer-3 resolution, it will no longer send ARP requests on the network. There really is very little ARP traffic on a network.
    – Ron Maupin
    Jan 25, 2017 at 15:59
  • Generally TCP/IP stacks will treat broadcast frames differently from unicast ones. So I wouldn't expect sending all frames to the broacast address to actually work unless the receiving TCP/IP stack was modified. Jan 25, 2017 at 15:59

When IP uses a MAC-based L2 for local transport, the L2 transport needs to be told the destination node. For this, the next hop IP address needs to be translated to a MAC address. With IPv4 this is ARP's function.

In the original Ethernet scheme (via electrial or logical bus), all nodes on the network physically received the L2 frame but everyone except for the destination dropped it. Today, switches use the L2 destination address for direct packet switching for efficiency. Effectively, they do the hubs' (or repeater's) job while omitting the extraneous copies.

Skipping ARP and subsequently L2 addressing would require the NIC to understand IP in order to drop unwanted packets (or the OS stack to deal with all that). Additionally, switches would also need to understand IP to work efficiently - IP is much more complex than Ethernet (which is why routers used to be a lot more expensive and less performant than switches), so your network concentrators would be more costly. (This probably isn't true today but it was for a very long time.)

Note that when Ethernet was invented, IPv4 didn't even exist (outside the labs) and IPv6 was in the far future. It was up to IP to make use of the existing infrastructure and technology.


Not disagreeing with a word of the other answers, but it's worth knowing that some IP networks are actually designed pretty like this.

It's rather niche, but Always-Broadcast is the usual form of networking in at least one application-specific networking world: professional theatre lighting with Art Net protocol.

The usual design is:

  • The network is a single isolated LAN.
  • Normally with a switch not a hub.
  • A single lighting desk sends Art Net packets which describe the dimmer status of the various lighting fixtures (and where they point, focus, filter settings and anything else you can control on the fixture).
  • All transmitted packets are sent as UDP broadcasts, normally to
  • Each output device only knows what "universe" (layer 4 address) it is.
  • One or more Art Net output units listen passively.
  • The output units then transmit the lighting control values over DMX-512 (trivial protocol over RS-485).
  • Each output "universe" drives 512 8-bit channels (an RGB light would be three channels). Very commonly there's only a single universe, but installations with more than a dozen are rare.
  • It's very common that several devices listen to the same universe ("house" lighting, backwashes, floods).
  • The passive units do normally send a small amount of status back to the lighting desk, also broadcast.
  • The protocol and the devices do support unicast (obviously with ARP) but it's not common except in larger installations or where there is a need for more network complexity.

From a networking point of view, it's generally considered pretty nasty. From a lighting design point of view, it means that the network effectively has no unit addressing, which makes it simpler to set up and maintain, especially given that duplicated universes are extremely common.


Yes, you're missing the effectiveness of hardware (MAC based) filtering vs. software (IP address based) filtering.

  • But filtering apart, would a hub-based network being able to work without an ARP active session?
    – gaetano
    Jan 25, 2017 at 13:07
  • Not without significantly modifying the OS on all the end systems. Jan 25, 2017 at 13:28
  • The 'modifications' would be limited to setting the network interfaces in promiscuous mode, IIRC. Your applications would need to be setup an MAC table to support sending traffic, I guess. Jan 25, 2017 at 15:31

Peter and Jaap are both right but more fundamentally, we use a layered model to ensure interoperability between vendors. The MAC layer uses a MAC address, full-stop. ARP allows us to discover those MAC addresses rather than entering them manually into a table.

  • 1
    Mine was a theoretical question. What is the point of using ARP if in an hub-based network we reach all the devices anyway? By using layer 2 broadcast address as a destination for every sent frame, I think that we can avoid the generation of ARP traffic. Do you agree?
    – gaetano
    Jan 25, 2017 at 14:06
  • 1
    @user, you still need to resolve the layer-2 address from the layer-3 address (ARP). If every host on a LAN receives the frame, the hosts without the specific MAC address can ignore the frame in the hardware. If you always use a broadcast MAC address, you interrupt every host for every frame because every host must examine the frame to see if the packet in the frame is for them, and that is undesirable. Dropping the frame at the hardware prevents that problem.
    – Ron Maupin
    Aug 2, 2018 at 15:20
  • that @RonMaupin. This is a strong motivation towards the usage ARP, even in a hub-based network..
    – gaetano
    Aug 2, 2018 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.