Reverse Address Resolution Protocol: Difference between revisions
imported>Kvng grammar. caps. word choice. WP:DUPLINK. |
imported>InternetArchiveBot Rescuing 0 sources and tagging 1 as dead.) #IABot (v2.0.9.5 |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Obsolete computer networking protocol}} | {{Short description|Obsolete computer networking protocol}} | ||
{{Internet protocol suite|link= | {{Internet protocol suite|link=Reverse ARP}} | ||
The '''Reverse Address Resolution Protocol''' ('''RARP''') is an obsolete computer [[communication protocol]] used by a [[client computer]] to request its Internet Protocol ([[IPv4]]) address from a [[computer network]], when all it has available is its [[link layer]] or hardware address, such as a [[MAC address]].{{Ref RFC|903}} The client broadcasts the request and does not need prior knowledge of the network topology or the identities of servers capable of fulfilling its request. | The '''Reverse Address Resolution Protocol''' ('''RARP''') is an obsolete computer [[communication protocol]] used by a [[client computer]] to request its Internet Protocol ([[IPv4]]) address from a [[computer network]], when all it has available is its [[link layer]] or hardware address, such as a [[MAC address]].{{Ref RFC|903}} The client broadcasts the request and does not need prior knowledge of the network topology or the identities of servers capable of fulfilling its request. | ||
RARP has been rendered obsolete by the [[Bootstrap Protocol]] (BOOTP) and the modern [[Dynamic Host Configuration Protocol]] (DHCP), which | RARP has been rendered obsolete by the [[Bootstrap Protocol]] (BOOTP) and the modern [[Dynamic Host Configuration Protocol]] (DHCP), which have much greater feature sets than RARP. | ||
RARP requires one or more server hosts to maintain a database of mappings of [[link layer]] addresses to their respective protocol addresses. MAC addresses need to be individually configured on the servers by an administrator. RARP is limited to serving only [[IP address]]es. | RARP requires one or more server hosts to maintain a database of mappings of [[link layer]] addresses to their respective protocol addresses. MAC addresses need to be individually configured on the servers by an administrator. RARP is limited to serving only [[IP address]]es. | ||
| Line 10: | Line 10: | ||
Reverse ARP differs from the [[Inverse Address Resolution Protocol]] (InARP), which is designed to obtain the IP address associated with a local [[Frame Relay]] data link connection identifier.{{Ref RFC|2390}} InARP is not used in [[Ethernet]]. | Reverse ARP differs from the [[Inverse Address Resolution Protocol]] (InARP), which is designed to obtain the IP address associated with a local [[Frame Relay]] data link connection identifier.{{Ref RFC|2390}} InARP is not used in [[Ethernet]]. | ||
== | == History == | ||
The Reverse Address Resolution Protocol (RARP) was introduced in the early 1980s to help devices, especially [[diskless workstation]]s, determine their IP addresses using only their hardware (MAC) addresses.<ref>{{cite web|url=https://usa-ip.com/the-origins-of-rarp-how-and-why-the-reverse-address-resolution-protocol-was-developed/|title=The Origins of RARP: How and Why the Reverse Address Resolution Protocol Was Developed|publisher=usa-ip.com|date=|accessdate=19 June 2025}}</ref> This was a common need in early network environments where local storage was unavailable for IP configuration. | |||
RARP was specified in RFC 903, published in June 1984 by David C. Plummer.<ref name="PLU">Plummer, David C,{{cite web|url=https://datatracker.ietf.org/doc/html/rfc903|title=RFC 903: A Reverse Address Resolution Protocol.|publisher=datatracker.ietf.org|date=1 June 1984|accessdate=19 June 2025}}</ref> Building on the original Address Resolution Protocol (ARP), RARP reused ARP’s message structure but reversed its function, allowing a device to query a RARP server for its corresponding IP address.<ref name="PLU"/> The protocol was widely adopted in [[UNIX]]-based systems for network booting.<ref name="PLU"/> | |||
Despite its utility, RARP had major limitations: It required static mappings, lacked support for additional configuration data, and could not operate across subnets. These drawbacks led to its replacement by more robust protocols like [[BOOTP]] and [[DHCP]].<ref name="PLU"/> Nonetheless, RARP laid the groundwork for later network boot technologies. | |||
==Modern day uses== | |||
Although the original uses for RARP have been superseded by different protocols, some modern-day protocols use RARP to handle MAC migration, particularly in virtual machines, using a technique originating in [[QEMU]]. | Although the original uses for RARP have been superseded by different protocols, some modern-day protocols use RARP to handle MAC migration, particularly in virtual machines, using a technique originating in [[QEMU]]. | ||
Examples include: | Examples include: | ||
* Cisco's [[Overlay Transport Virtualization]] (OTV). RARP is used to update the layer 2 forwarding tables when a MAC address moves between data centers. | * Cisco's [[Overlay Transport Virtualization]] (OTV). RARP is used to update the layer 2 forwarding tables when a MAC address moves between data centers. | ||
* [[VMware vSphere]]'s vMotion.<ref>{{Cite web |last=Deshpande |first=Venky |date=22 July 2013 |title=VXLAN Series – How vMotion impacts the forwarding table – Part 6 |url=http://www.soviet-empire.com/ussr/viewtopic.php?t=50411 |access-date=15 March 2023 |website=vmware}}</ref> RARP is used when a VM MAC moves between hosts. | * [[VMware vSphere]]'s vMotion.<ref>{{Cite web |last=Deshpande |first=Venky |date=22 July 2013 |title=VXLAN Series – How vMotion impacts the forwarding table – Part 6 |url=http://www.soviet-empire.com/ussr/viewtopic.php?t=50411 |access-date=15 March 2023 |website=vmware }}{{Dead link|date=November 2025 |bot=InternetArchiveBot }}</ref> RARP is used when a VM MAC moves between hosts. | ||
==See also== | ==See also== | ||
Latest revision as of 03:07, 1 November 2025
Template:Short description Script error: No such module "Sidebar".
The Reverse Address Resolution Protocol (RARP) is an obsolete computer communication protocol used by a client computer to request its Internet Protocol (IPv4) address from a computer network, when all it has available is its link layer or hardware address, such as a MAC address.Template:Ref RFC The client broadcasts the request and does not need prior knowledge of the network topology or the identities of servers capable of fulfilling its request.
RARP has been rendered obsolete by the Bootstrap Protocol (BOOTP) and the modern Dynamic Host Configuration Protocol (DHCP), which have much greater feature sets than RARP.
RARP requires one or more server hosts to maintain a database of mappings of link layer addresses to their respective protocol addresses. MAC addresses need to be individually configured on the servers by an administrator. RARP is limited to serving only IP addresses.
Reverse ARP differs from the Inverse Address Resolution Protocol (InARP), which is designed to obtain the IP address associated with a local Frame Relay data link connection identifier.Template:Ref RFC InARP is not used in Ethernet.
History
The Reverse Address Resolution Protocol (RARP) was introduced in the early 1980s to help devices, especially diskless workstations, determine their IP addresses using only their hardware (MAC) addresses.[1] This was a common need in early network environments where local storage was unavailable for IP configuration.
RARP was specified in RFC 903, published in June 1984 by David C. Plummer.[2] Building on the original Address Resolution Protocol (ARP), RARP reused ARP’s message structure but reversed its function, allowing a device to query a RARP server for its corresponding IP address.[2] The protocol was widely adopted in UNIX-based systems for network booting.[2]
Despite its utility, RARP had major limitations: It required static mappings, lacked support for additional configuration data, and could not operate across subnets. These drawbacks led to its replacement by more robust protocols like BOOTP and DHCP.[2] Nonetheless, RARP laid the groundwork for later network boot technologies.
Modern day uses
Although the original uses for RARP have been superseded by different protocols, some modern-day protocols use RARP to handle MAC migration, particularly in virtual machines, using a technique originating in QEMU.
Examples include:
- Cisco's Overlay Transport Virtualization (OTV). RARP is used to update the layer 2 forwarding tables when a MAC address moves between data centers.
- VMware vSphere's vMotion.[3] RARP is used when a VM MAC moves between hosts.