Two things:

First:
I'm considering a network topology model where I want to have strict client isolation at layer2 throughout the customer-access layer of the network, but still allow certain client-to-client communication via the router. That's what local-proxy-arp is for, and it's exactly how to accomplish this.

Another design goal is to force clients to use DHCP for IP addressing with arp=reply-only + dhcp adds arp entries upon lease

- Mikrotik, could you add another ARP configuration for "reply-only-local-proxy-arp" ? This would be the only way to accomplish both goals w/o using bridge firewall filters/

Second:
I was doing some packet sniffing to confirm that local-proxy-arp does in fact allow the router to send ARP requests as it would in "arp=enabled" mode.... but I found something that seems wrong for arp=reply-only mode. In this mode, any packets to IP addresses not in the ARP table will be FORWARDED to the interface, but with the SRC and DST mac addresses both set to the Mikrotik's MAC address! Is this a bug or a feature?

Test done on a 2011 series router running v6.40.

Very interesting. Will try out at home.

You can skip that local-proxy-arp stuff (just use arp:reply-only) if you are willing to hand out 32-bit subnet-masks (255.255.255.255) to your clients via DHCP.
This way the only arp-request a client ever asks for is its default gateway.

Handing out 32-bit subnet-masks is quite common nowadays.

This same src/dest MAC request I assume it is done to update MAC tables and switching tables in potential switches on the network. Or some other more obscure reason on devices which do ARP sniffing...

You can skip that local-proxy-arp stuff (just use arp:reply-only) if you are willing to hand out 32-bit subnet-masks (255.255.255.255) to your clients via DHCP.
This way the only arp-request a client ever asks for is its default gateway.

I understand that. However, I don't want to block east/west communications at layer 3 if two customers decide they want to make a vpn between their houses or something like that. I know it's an edge case, but I don't want to limit what my customers can do with a public IP address.

This same src/dest MAC request I assume it is done to update MAC tables and switching tables in potential switches on the network. Or some other more obscure reason on devices which do ARP sniffing...

I'm thinking it might be the mechanism by which Mikrotik is "disabling" the sending of ARPs in one direction only - i.e. it has a 'default' MAC address of "self" except where found in the ARP cache.... in any case, it seems odd to me that the router should actually forward packets for which no layer2 destination address is known. If ARP is in standard mode, then it never actually forwards packets until an ARP reply is received.

If you hand out /32 subnet mask with public IPv4, your customers can reach any other customer, just like handing out /24 subnet masks with local proxy arp.

The only difference: local-proxy-arp is dangerous and ugly.
/32 subnet masks are elegant and very handy

A lot of providers do this already. /32 subnet masks are more common than you might think.

You assume per-customer VLAN, which we're not going to do. One of the goals for this design is to reduce the configuration complexity, and keeping a unique vlan per user is going to run into issues whenever some technician configures a radio with the same vlan as some other customer.

We currently give /32 per customer on our business clients, and have been doing so for years. But those are layer2-isolated. For a residential play, we need something that's simpler and more cookie-cutter. DHCP with Option 82 seems to be the way to go, and blocking east/west traffic at layer2 is a high priority. In fact, I'm prepared to give up the ability to allow layer3 east/west for residential customers if it can't be done with forced dhcp.

If I had my druthers, I'd also have WPA2-Enterprise enabled on the sectors tied to the radios themselves so that no one may connect to the system at all w/o the device being provisioned centrally.

I don't understand what you mean.

In my setup all customers share the same VLAN (Broadcast Domain, VPLS instance, whatever you might call it).
Layer-2 isolation between all clients is strictly enforced throughout the whole network.
The Standard Gateway is configured to arp:reply-only, the dhcp server is configured to add-arp-for-leases and to hand out a /32 subnet mask.
Thus no broadcast packet will ever leave the customer facing interface.

The standard gateway still is configured with /22 subnet mask.
This assymetric configuration regarding subnetmasks works flawlessly.
Nonetheless you also could configure a completely unrelated ip-address with a /32 subnet mask on the default gatway interface (cisco calls that ip-unnumbered).

So essentially it is the same you're trying to achieve with local-proxy-arp. Just better and cleaner.

Perhaps my understanding of how you're handing out a /32 is different than the way we're doing it.

In our setup (Cisco routers, btw - not Mikrotik on the network side):
Interface Gi0/0/0.500
encapsulation dot1q 500
ip unnumbered loopback100
ip verify unicast source reachable-via rx
!
ip route 192.0.2.75 255.255.255.255 Gi0/0/0.500

This puts exactly one IP address onto the customer's VLAN and keeps the customer from being able to use any IP but the one routed to their interface.
The customer configures their equipment (or we configure our Mikrotik CPE device) with 192.0.2.75/24 default GW = 192.0.2.1
Cisco performs proxy arp so that any customer may reach the IP address of any other customer in that range.
E.g. a customer has two sites and they build a VPN between them.


Now - in Mikrotik, there is the arp: reply-only + dhcp add arp on lease mechanism, so you can force this behavior but on a shared vlan. I get this.
However, there's a little bit of difference if we use a single VLAN + arp=reply-only.
To my knowledge, this mode does not perform proxy arp functionality, so customers would need to arp / communicate directly at layer 2 if they're in the same IP range. If that shared vlan performs client isolation, then customers within that network may not communicate directly with each other in this regime.

And I see what you're saying about use /32 at each customer site. If the CPE only has its own IP and the default GW IP on the wan interface, it's going to send everything to the default GW even if it's in the "same" subnet... but how do you handle BYOD CPE? In other words, it's easy to say that I'll put a /32 on the CPE whenever it's Mikrotik, but what if the customer is using some device that doesn't support this? Our residential play is going to REQUIRE BYOD - we're not including a router / WAP. PPPoE would work, but I'm not going to do that. DHCP is far and away the leading standard for broadband delivery here in the US - and I don't want to have to end up dealing with username/password management involving the customers because it's going to lead to more tech support calls as the customers invariably forget their credentials and go buy the latest netgear mega WiFi thing at Office Depot with 12 antennas and built in virus protection, net accelerator, buzz buzz buzz....


Basically, our current /32 delivery mechanism is done on the ISP side so that the CPE can be anything the customer wants to use, but it requires each attachment circuit be a unique layer 2 domain so that our side knows to perform proxy arp. This wouldn't work in a shared broadcast domain w/o local-proxy-arp mode - which is mutually exclusive to reply-only mode. We do this on our business service (we've been business-only until just recently) but manually provisioning residential service would not be a scalable practice.

Does this better explain my situation?

I think it would be more flexible if ROS were to break apart the ARP configuration into its separate components:
arp-reply-mode: on, off, proxy-arp, local-proxy-arp
arp-send-mode: on, off

With arp broken into these categories, you can mix and match whatever mode you like. In my case, I would use:
arp-reply-mode: local-proxy-arp
arp-send-mode: off