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!