Ethan Banks On productivity.

OECG – Chapter 5


After ICMP, we get into some of the protocols used so that hosts can find out about each other and about themselves.

  • ARP – address resolution protocol, RFC 826. ARP is how a host who knows the IP address of his destination finds out the MAC so that he can properly put a frame on the ethernet. An ARP request is a broadcast with no IP header. The response will come from the host on the wire with that IP address, including the MAC.
  • Proxy ARP, RFC 1027. Proxy ARP is when a device responds to an ARP request on behalf of another device. Often, this is because a host thinks the destination he wishes to talk to is locally attached, when in fact his destination is on the far side of a router (possibly because the host is using classful masks, when in fact the classful network has been subnetted). The router will response to the ARP with his own interface MAC, the host will send the packet to the router, and the router then forwards the packet wherever it needs to go.
  • RARP – reverse ARP, requires a server. It’s for a host that doesn’t know his own IP address. He puts a RARP out on the wire that includes his IP address. The RARP server gets the request, finds the MAC in his table, and responds to the requester with the appropriate IP address. If there’s no matching MAC in the RARP server’s table, the requesting host is out of luck. A RARP looks just like an ARP, except that the MAC he’s seeking is his own, and the IP is a (Reversed, get it?) RARP servers only work locally.
  • BOOTP, RFC 951. These aren’t ARP messages, but still serve the purpose of helping a host discover his IP address. BOOTP messages are UDP over IP. BOOTP will also serve to the requester not only his IP, but also info like the subnet mask, default gateway, name servers, possibly where he can find an OS image, etc. BOOTP has the same limitation as RARP, in that the BOOTP server has to find a MAC in his table matching the requester MAC, or the requester is out of luck. BOOTP servers can be centralized. You can configure a router to forward BOOTP broadcasts to a central BOOTP server (more on this in a bit).
  • DHCP, dynamic host configuration protocol. An evolution of BOOTP, DHCP allows for hosts to get their IP addresses, but without the server having to have a table of each and every MAC that might ask. DHCP introduces the concept of leasing, whereby a host will lease an IP address for a defined amount of time, renewing at intervals, but can release the IP address back to the pool. DHCP also support dynamic resigistration of the hostname with the just-assigned IP address in DNS (put to heavy use in Windows 2000 networks). DHCP is also intended to work centrally, where a DHCP relay agent will forward DHCP broadcasts from locally attached subnets to the DHCP server. A DHCP relay agent turns the DHCP broadcast into a directed datagram. Specifically, let’s say a host on the network is seeking an IP address from a DHCP server. And let’s say that the DHCP server doesn’t live on the local network – he’s So the host puts a DHCP broadcast on the wire, “Hey, I need an IP!”, with a source and destination of The router servicing is configured as a DHCP relay agent (“ip helper-address”). The router will take the broadcast, repackage it as a unicast from source to destination and forward it on. The DHCP server will get the address, see the source, allocate an address from his 192.168.100.x pool, and respond to The router will get this request, and forward it back to the, where it will hit the network as a broadcast. The requesting host will see the response to his request.
  • Oh and by the way – Cisco routers can be DHCP servers as well, not that most of us use them that way. But it can be done, and here’s sample IOS code for a DHCP server servicing the network, serving up as the name server and as the default gateway, leasing the IP for 3 days, 12 hours and 0 minutes:
    • ip dhcp pool subnetX
      • network
      • dns-server
      • default-router
      • lease 3 12 0
  • For more on configuring a DHCP server, check here.


By Ethan Banks
Ethan Banks On productivity.

You probably know Ethan Banks because he writes & podcasts about IT. For example, he co-authored "Computer Networks Problems & Solutions" with Russ White.

This site is Ethan on productivity--not tech so much.

Find out more on his about page.