An IPv4 router has proxy ARP enabled on every interface by default; what risks does that carry, and how do you judge turning it off?
answer
- convenience that hides mistakes
- unauthenticated claim to attract traffic
- no RFC mandates it
- failure arrives on the cache timer
basics
~20 sDefault proxy ARP is an implementation choice, not an RFC rule. It hides wrong host configuration, silently routes traffic through the router and blurs spoofing signals; disable it where nothing designed depends on it, expecting failures as caches expire.
solid answer
~40 sNo RFC mandates proxy ARP: RFC 1027 documents it and RFC 1812's ARP rules never mention it, so a default-on setting is the implementation's choice. Left on everywhere, it lets hosts with wrong masks or addresses keep working through the router, so errors pile up unseen until the router changes; it makes the router an unplanned path that can bypass filtering, as RFC 1027 itself warns; and it produces the one-MAC-many-IPs pattern that poisoning also produces. Before disabling it, find who depends on it — hosts caching remote IPs at the router's MAC, and deliberate designs like a NAT or VPN pool numbered from the LAN subnet — fix masks at their source, and expect breakage to arrive as host ARP entries age out, not at the moment of the change.
go deeper
Remember that proxy ARP being on by default is a product setting, not a protocol rule, and that it lets broken host configurations keep working.
Explain how each risk follows from the mechanism: an unauthenticated reply, a router silently on the path, and caches holding the router's MAC.
Show the change plan: find dependants from ARP caches and deliberate designs, fix masks at the source, and watch for failures arriving as entries age out.
Weigh default-on convenience against hidden coupling and blurred security signals, and set a policy of off-by-default with documented exceptions.
## What "on by default" means in the standards No RFC requires an IPv4 router to run proxy ARP. RFC 1027 documents the technique; RFC 1812, the requirements for IPv4 routers, makes routers that implement ARP follow the host requirements and adds a few rules of its own — queue packets while resolving, never believe a reply claiming a broadcast or multicast link-layer address — but none about proxy replies. Whether a router answers ARP for others out of the box is therefore an **implementation choice**: some router platforms have historically enabled it on every routed interface, while Linux, as one example, leaves it off per interface unless configured. An interviewer asking "is it on by default?" wants to hear that distinction, not a vendor's value presented as protocol. ## The risks of leaving it on everywhere 1. **The router silently becomes the path.** Any host that wrongly believes a remote address is on-link — a too-wide mask, a static address copied from another subnet, a host plugged into the wrong segment — keeps working, because the router answers for it. Configuration errors accumulate unseen and surface together on the day the router changes. 2. **It is interception by design.** A proxy reply is an unauthenticated claim, "send this address's traffic to me". When the router is the authorised one, that is the feature. But every flow it attracts now crosses a device the hosts never chose, and RFC 1027 warns that a gateway answering for foreign networks could be used to reach them while bypassing the security checks at the IP gateways. A dual-homed box with proxy ARP on can become an unplanned path around a firewall. 3. **It blurs a security signal.** One MAC claiming many IP addresses is how ARP poisoning looks from a victim's cache. A router that legitimately proxies produces the same picture, so monitoring either ignores it or alarms constantly — and a real forged claim can hide in that noise. 4. **Cache fragility.** RFC 1122 §2.3.2.1 says the prevalence of proxy ARP "has significantly increased the likelihood that cache entries in hosts will become invalid", which is why it made a cache-flushing mechanism mandatory for hosts and suggested timeouts on the order of a minute where proxy ARP is used. Replace the proxying router and every host holds the old MAC for every proxied address until those entries expire. 5. **More broadcast, bigger caches.** Hosts ARP individually for every remote address they think is local, instead of resolving one gateway. RFC 950, weighing RFC 925's ARP-based scheme against explicit subnets, noted that broadcast cost grows with the number of LANs and the gateways' translation caches with the number of hosts. | Concern | Proxy ARP on everywhere | Off except where designed | |---|---|---| | Wrong masks | hidden | fail fast, get fixed | | Path a host's traffic takes | decided by whichever router answers | the configured gateway | | One-MAC-many-IPs signal | routine noise | worth investigating | | Router replacement | cache-driven outage for dependants | ordinary gateway change | ## How to judge turning it off - **Find the dependants first.** Hosts whose ARP caches map remote addresses to the router's MAC are relying on it; so are designs that need it on purpose (a NAT pool or a VPN client pool numbered from the LAN's own subnet, a Mobile IP home agent). - **Fix the cause, not the router.** Correct the masks at their source — the DHCP scope or the provisioning template — so hosts send remote traffic to their gateway. - **Expect delayed failure.** Disabling proxy ARP stops new replies, but cached mappings still point at the router, which still forwards frames addressed to it. Breakage arrives as entries age out, on a timer the host implementation sets, so keep a rollback window open long enough to see it. - **Keep it where it is designed in**, on those interfaces only, and document why, so the next engineer does not "harden" it away. ## What to check after the change - Hosts that lost reachability to other subnets inside their own address range, but not to the internet, are the dependants you missed. - Unanswered ARP requests for remote addresses, visible in a capture on the segment, name exactly which hosts still carry a wrong mask. ## A senior answer in one breath Proxy ARP on by default is a convenience that converts host misconfiguration into router dependency and puts an unauthenticated traffic-attracting claim on every interface. Turn it off where nothing needs it, after finding what does, and expect the failures to arrive on the cache timer rather than at the moment of the change.
- Why did RFC 1122 make ARP cache flushing mandatory for hosts?RFC 826 suggests but does not require a timeout. RFC 1122 §2.3.2.1 says proxy ARP made it much more likely that cached entries become invalid, for example when the proxying router changes, so hosts MUST have some mechanism to flush stale entries; for proxy ARP situations it suggests timeouts on the order of a minute.
- How can proxy ARP create a path around a firewall?A router or dual-homed host that proxies answers ARP on one segment for addresses it can reach through another interface, so hosts send it traffic that the network design meant to pass through the firewall's gateway. RFC 1027 tells gateways not to answer for foreign networks for exactly this reason.
saying these in an interview costs you the question
- RFC 1812 requires IPv4 routers to enable proxy ARP on every interface.
- Disabling proxy ARP breaks dependent hosts immediately, so the impact is easy to see.
- Proxy ARP is harmless because only the router can send the replies.
- If no one has complained, no host depends on proxy ARP.
- Proxy ARP replies are authenticated, so they cannot be confused with spoofing.