El Protocolo de resolución de dirección inversa ( RARP ) es un protocolo de comunicación de computadora obsoleto utilizado por una computadora cliente para solicitar su dirección de Protocolo de Internet ( IPv4 ) de una red de computadoras , cuando todo lo que tiene disponible es su capa de enlace o dirección de hardware, como una MAC dirección . El cliente difunde la solicitud y no necesita conocimientos previos de la topología de la red ni de las identidades de los servidores capaces de atender su solicitud.
RARP se describe en la publicación RFC 903 del Grupo de trabajo de ingeniería de Internet (IETF). [1] El protocolo Bootstrap (BOOTP) y el moderno Protocolo de configuración dinámica de host (DHCP) lo han vuelto obsoleto , ambos admiten un conjunto de características mucho mayor que RARP.
RARP requiere que uno o más hosts de servidor mantengan una base de datos de asignaciones de direcciones de capa de enlace a sus respectivas direcciones de protocolo. Las direcciones de Media Access Control (MAC) deben ser configuradas individualmente en los servidores por un administrador. RARP se limita a proporcionar solo direcciones IP .
ARP inverso difiere del Protocolo de resolución de dirección inversa (InARP) descrito en RFC 2390, que está diseñado para obtener la dirección IP asociada con un identificador de conexión de enlace de datos Frame Relay local. InARP no se utiliza en Ethernet .
Usos modernos
Aunque los usos originales de RARP han sido reemplazados por diferentes protocolos, algunos protocolos modernos usan RARP para manejar la migración de MAC, particularmente en máquinas virtuales, usando una técnica que se origina en QEMU . Algunos ejemplos son:
- Virtualización de transporte superpuesto (OTV) de Cisco . RARP se utiliza para actualizar las tablas de reenvío de capa 2 cuando una dirección MAC se mueve entre centros de datos.
- VSphere vMotion de VMware. [2] RARP se usa cuando un MAC de VM se mueve entre hosts.
Ver también
Referencias
- ^ RFC 903, Un protocolo de resolución de dirección inversa , R. Finlayson, T. Mann, J. Mogul, M. Theimer (junio de 1984)
- ^ https://blogs.vmware.com/vsphere/2013/07/vxlan-series-how-vmotion-impacts-the-forwarding-table-part-6.html