# Why do we need ARP and hardware addresses.

## dE_logics

Assuming a network connected via a switch and there's no ARP protocol, the node which wants to send requests to y.y.y.y it will send it via the switch which can broadcast to all nodes. If there's a response from one node, the switch can remember (cache) the port form which the response came and the associated IP... so why is ARP needed.

Of course with the above model I can see a lot of loopholes (e.g. multiple requests to/from a node), but I want people to tell me all of those.

----------

## Ant P.

You're right, ARP isn't needed! All you have to do is throw away all your Ethernet hardware (because that relies on it at a fundamental level), and use a non-broadcasting link layer like token ring or PPP.

----------

## papahuhn

 *dE_logics wrote:*   

> Assuming a network connected via a switch and there's no ARP protocol, the node which wants to send requests to y.y.y.y it will send it via the switch which can broadcast to all nodes. If there's a response from one node, the switch can remember (cache) the port form which the response came and the associated IP... so why is ARP needed.
> 
> Of course with the above model I can see a lot of loopholes (e.g. multiple requests to/from a node), but I want people to tell me all of those.

 

On a basic level, that should work even with current Layer-2 switches, if end-devices adapted their network stacks. IP A sends to IP B as layer 2 broadcast. Node B responds to IP A via layer 2 unicast. The switch populates its forwarding table as usual. However:

- The first packet of a connection would be seen in the whole broadcast domain. When using TCP, neighbors see the port numbers, options and initial sequence numbers. 

- In a failover configuration - shared virtual IP between multiple nodes - how should the failover be carried out? Explicit Gratuitous ARP is not possible anymore, and an implicit realization via "active data" is not reliable as the transport layer might be idle.

- The same problem would exist with MAC-relocalization in virtual environments, where virtual machines are moved from one host to another. ESX servers use Reverse-ARP to propagate MAC-relocalization to physical switches.

Still, the idea is somehow neat. Routing table entries would not need a next hop IP any more. Unknown destination IPs will be layer-2-broadcasted initially. If the destination IP is in the same subnet, the destination responds itself, if not, the gateway will feel responsible to route the packet.

----------

## gentoo_ram

To the O.P., the reason it doesn't work the way you describe is because the ethernet switch doesn't look at the IP layer.  As a matter of fact, the switch only has to look at the first 12 bytes of the ethernet packet (the source and destination ethernet addresses) to decide what to do with the packet.  That's why it's called an "ethernet switch", not an IP switch.  You can run other protocols over ethernet other than IP.

Feel free to run IP over some other layer-2.  Token ring... SDLC... PPP... whatever you'd like.

----------

## dE_logics

Ok, I see. Thanks for the clarification.

----------

