Why don't routers answer ARP requests for IP addresses they can handle even if they aren't assigned that IP address themselves?

Question

An ARP request is made to know the MAC address of the device that has some specific IP assigned. This way we will be able to know what MAC address we should set to send out IP packet.

If a device wants to send a packet to another device in an external network, it first looks at its default gateway's IP address, then it makes an ARP request to know the MAC address of the device that has the gateway's IP address assigned, and then sends the IP packet using that MAC address.

Let's say that we didn't have any default gateway ip address configured in the device that wants to send IP packets. Let's say the router didn't have any IP address assigned either. But the router has an entry in its routing table entry to redirect the packet that the device wants to send. Then...

1. The device sends an ARP request asking which device has the IP address of the packet that it wants to send.
2. Even though the router itself doesn't have that IP address assigned it should answer with its own MAC address anyways because it can redirect the IP packet to the correct destination.

I haven't made a proof of concept to see if the router would actually behave as I said or not, but I have understood that the router just won't answer to the ARP request in this case. Why though?

Answer 1

Let's say the router didn't have any IP address assigned either

The router would not be an IP router for that router interface because it would not know about the network directly connected to it. A router not having an IP address for an interface means that the router cannot use that interface for IP. Putting an IP address (either IPv4 or IPv6) enables IP for that interface. Routers route packets between different networks, and a router that does not know how to reach a network will drop any packets destined for that network. The IP address on the router interface tells the router how to reach that network. You could, of course, have a router interface for a different network protocol, e.g. IPX or AppleTalk, that has no IP address, but that router interface would not route IP.

Proxy ARP (a bad idea) if configured on a router will let the router answer for a MAC address on a different network, but the router needs to know what the originating network is so that responses can be sent back to that network (remember that most transport or application-lay protocols are request/response).

Answer 2

OK, so you have these (theoretical) options:

• The TCP/IP way:

  Any time I want to send a packet to a new IP not on the local network:

  • I lookup the IP of the default gateway (in the local routing table)
  • I lookup the MAC address of that default gateway (in the local ARP cache since it's the default gateway and I use that IP all the time)
  • I send my packet to that MAC address.

  Result:

  • Packets sent: 1.
  • Packets received: 0.
  • Latency before sending the packet: virtually 0.
  • Size of my ARP table: very small (only devices on my local network).

• The Adrian way:

  Any time I want to send a packet to a new IP not on the local network:

  • I send an ARP request to know where to send my packet
  • I wait for the ARP response
  • I send my packet to that MAC address. This either requires buffering the packet until I get an ARP response, or relying on upper layers to retransmit.

  Result:

  • Packets sent: 2.
  • Packets received: 1.
  • Latency before sending the packet: RTT from device to router + processing time by router + possibly retransmit timeout.
  • Size of my ARP table: possibly very large (since every single destination IP would need an entry).

Option 1 is how TCP/IP works. Option 2 is what you are asking about. Why would anyone think option 2 is better?

Of course option 2 does not actually work on TCP/IP devices. It could possibly work if you set the local network IP to 0.0.0.0/0 (so that all IP packets are sent to the local network) and the router had proxy ARP enabled (for any IP, which I don't think would be possible on most devices).

Answer 3

As many have answered, the function to providing routing when an endstation is not aware of a router is called Proxy ARP. It used to be commonly enabled by routers, to provide service to misconfigured / underconfigured end stations. But Proxy ARP doesn't scale well--it causes every end stations to essentially create a static host route for every IP address it ever wants to connect to (in the form of their ARP caches). It probably also upsets security folks--we don't want that.

The other aspect you ask about is why the router needs an IP address in order to provide routing service. In general, a router needs to know what networks are locally connected to it. It needs this information so that, when attempting to deliver a packet, it can know when and if it should use the Layer 2 network service to deliver the frame, or if it should to a next hop route (whether static, learned, or last resort). This is just like any other IP processing node.

So you could invent some other way for a router to understand when a packet gets local delivery or is forwarded, one that doesn't require it having an IP address. But now you are creating a parallel but different behavior which, combined with the limits of Proxy ARP, is no better (and probably worse) than the current way it works.

Again, what routers do to decide where to forward a packet is no different than what non-routers do--it's just that non-routers usually only have two choices: deliver locally or forward to a gateway (router). A router may have several local networks, and several next-hop options. But at the lowest level, routers and non-routers have routing tables that work the same way. It would be weird (as in non-obvious, requiring higher cognitive load) if it were otherwise.

Answer 4

Let's say that we didn't have any default gateway ip address configured in the device that wants to send IP packets.

Without a route & gateway to the destination, a host can only drop the packet. There is no fall-back mode and generally, you route packets where you know they are right - it's not try and error.

Let's say the router didn't have any IP address assigned either.

A node without IP address isn't reachable. When you can't reach the gateway, the route isn't usable.

But the router has an entry in its routing table entry to redirect the packet that the device wants to send.

What you refer to sounds like proxy ARP - that is only used for workarounds and mostly only temporarily.

Consider the default route 0.0.0.0/0 that fits any IP address. You are suggesting that the router then answers to any ARP request? That's not how IP works.

Picture a network that has two routers attached, one for the Internet, the other for the corporate (large) network. Each router has a default route (ultimately leading to to the Internet) - which one should answer to an ARP request? From whom? By logic, the Internet router could try to apply the same logic and ARP for an Internet address instead of using its routing table. If the corporate router answers instead of the real uplink router, the packets goes the wrong direction. As a result, any non-trivial networks becomes either hard or even impossible to handle.

On the other hand, if a router has no IP address on one of its interfaces, how is it supposed to know when to answer to ARP requests on another interface, ie. which addresses are actually local to it when other routers proxy remote addresses?

At the end of the day, your proposal begins to sound much like bridging, not routing. It's impossible to scale bridging to the size of a global network.

Answer 5

Apparently someone did do that. Btw it's called Proxy ARP.

The linked youtube video also illustrates why you shouldn't do that. It's basically because you'd fill the ARP cache with more and more entries, one for each IP address in the internet that you want to communicate with.

Also, you need an IP address assigned to have IP enabled. (See Ron Maupin's comments).

---

EDIT:

I struggled really hard to understand why exactly you need an IP address assigned to have IP enabled so I posted a different question to discuss every explanation given in the other answers. In case you want to check it out, here is the link.