In classical TCP/IP, when a host knows its hardware (MAC) address but not its own IP address, which protocol can it use to discover the IP address?

Introduction / Context:
Early diskless workstations and embedded devices sometimes booted knowing only their MAC address. They needed a way to obtain an IP address from a server on the local network before higher-level configuration could proceed.

Given Data / Assumptions:

• Host starts with a known MAC address.
• IP address is unknown and must be discovered.
• Legacy TCP/IP environment (pre-DHCP or alongside BOOTP/DHCP).

Concept / Approach:
RARP (Reverse Address Resolution Protocol) maps a known hardware address to an IP address, essentially the inverse of ARP. A RARP server listens on the LAN, receives a RARP request containing the client’s MAC, and replies with the corresponding IP. Modern networks typically use BOOTP/DHCP instead, but RARP is the direct answer to the legacy question.

Step-by-Step Solution:
Identify the need: MAC → IP mapping.Match protocol to function: that is RARP.Note that ARP does the opposite (IP → MAC) and is not applicable here.

Verification / Alternative check:
DHCP/BOOTP workflows can also assign IPs using broadcast discovery, but the specific “reverse” of ARP was historically RARP.

Why Other Options Are Wrong:
ARP: Resolves IP to MAC, not MAC to IP.

IGMP: Manages multicast group membership.

ICMP: Control/diagnostic messaging (e.g., echo).

None of the above: Incorrect because RARP fits exactly.

Common Pitfalls:
Mixing up ARP and RARP directions; remembering that “Reverse” in RARP indicates MAC → IP assistance.

Final Answer:
RARP