In yesterday's Network+ tutorial, we talked about the importance of Address

Resolution Protocol (ARP) in today's networks. A host PC must have the MAC and
IP addresses of a remote host in order to send data to that remote host, and it's
ARP that allows the local host to request the remost host to send the local host its
MAC address through an ARP Request.

The ARP Request is a layer two broadcast, and like all L2 broadcasts it has a
destination MAC address of ff-ff-ff-ff-ff-ff. Switches forward broadcasts, but
routers do not, which brings up a basic problem. If there's a router between two
hosts, how can one possibly send an ARP Request to the remote host, since routers
do not forward broadcasts?

That's where Proxy ARP comes in. For this example, let's assume that HostA is on a
network segment connected to RouterA's ethernet0 interface, and HostB is on a
network segment connected to RouterA's ethernet1 interface. HostA wants to
send data to HostB, but doesn't have HostB's MAC address. An ARP Request from
HostA will stop at the router - but with Proxy ARP, the router will actually answer
the ARP Request with the MAC address of the router interface that received the
ARP Request!

In this case, RouterA will respond to the ARP Request with the MAC address of it's
own ethernet0 interface. This is transparent to HostA - when HostA sends data to
HostB, the destination IP address will be that of HostB, but the destination MAC
address will be that of RouterA's ethernet0 interface.

Since we've now discussed ARP and Proxy ARP, I do want to mention RARP -
Reverse Address Resolution Protocol. RARP allows a host device to send a request
for its own IP address, and this response will be answered by a RARP server. You
don't see RARP that often anymore, since DHCP does the same thing and much
more, but you should know what RARP does. And if you're not sure what DHCP
does - don't miss my next Network+ exam tutorial!