PONTIFICIA UNIVERSIDAD CATÓLICA

DEL ECUADOR

MAESTRÍA EN REDES DE COMUNICACIONES

TECNOLOGÍA DE INTERNET Y TCP/IP

RFC 903
RARP (REVERSE ADDRESS RESOLUTION
PROTOCOL)

Carlos Darwin Aguilar Mora

Quito, septiembre 2013

 TRABAJO DE INVESTIGACIÓN

RFC 903

OBJETIVO GENERAL

Investigar, analizar y emitir criterios acerca de RARP (Reverse Address Resolution Protocol),
especificado en el RFC 903.

OBJETIVOS ESPECÍFICOS

• Investigar el protocolo ARP (Address Resolution Protocol), que realiza una operación
complementaria u opuesta a RARP
• Identificar la problemática que resuelve RARP.
• Listar las características principales de RARP.
• Esquematizar el funcionamiento de RARP.
• Detallar aspectos de RARP como configuración, menajes y formatos.
• Relacionar RARP con el trabajo.

RESUMEN

El RFC 903 propuesto en 1984 por Ross Finlayson, Timothy Mann, Jeffrey Mogul y Marvin
Theimer de la Universidad de Stanford, sugiere un método para que equipos del estilo de
terminales tontas que no tienen almacenamiento y por ende un sistema operativo, puedan obtener
una dirección IP a partir de su dirección física o MAC, para lograr conectividad.

Antes de RARP, en el RFC 826 se define ARP cuyo propósito es resolver direcciones físicas a
partir de una dirección IP, esto con el objetivo de permitir la comunicación entre emisor y receptor
dentro de una red local. Sin embargo existía el inconveniente de equipos que por su naturaleza o
por el fin para el que estaban diseñados, no disponían de almacenamiento que permitiera la
instalación del sistema operativo y tampoco almacenar información como la dirección IP, para esta
problemática nace el protocolo RARP que en forma opuesta a ARP permite obtener una dirección
IP a partir de una dirección MAC.

Si bien RARP fue útil en su momento, éste fue remplazado por BOOTP (Bootstrap Protocol) que
incluía ciertas mejoras con respecto a RARP, posteriormente nace DHCP (Dynamic Host
Configuration Protocol) que permite asignar a más de una dirección IP, otros parámetros
importantes de red como: máscara de subred, puerta de enlace, servidores DNS entre otros.

PROBLEMÁTICA

Cualquier dispositivo con una interface de red posee una dirección física, pero para acceder a la
red requiere una dirección IP, la cual debe ser almacenada en algún medio. El problema surge con
dispositivos que no cuentan con almacenamiento para guardar la dirección IP, estos dispositivos
por lo general son terminales que no cuentan con todos los recursos y que utilizan la red para
acceder a recursos remotos.

Para solucionar este inconveniente se crea RARP que permite asignar una dirección IP a partir de
una dirección física, a equipos que no disponen de almacenamiento.

Para ello los dispositivos o hosts envían una solicitud broadcast y el servidor RARP responde con
un mensaje unicast, como se puede ver en la figura 1.

RFC 903
Carlos Aguilar Mora. 1
 Figura 1: Solicitud y respuesta RARP

ÁMBITO

Los paquetes RARP se encapsulan en tramas de la capa de enlace de datos, tienen el mismo
formato que ARP, pero con la particularidad de que en el campo physical type posee el valor 8035
(en hexadeciamal), para identificar que la trama contiene un mensaje RARP.

En la figura 2 se muestra el encapsulamiento a nivel de capa de enlace:

Figura 2: Mensaje RARP encapsulado en una trama.

CARACTERÍSTICAS

• Requiere uno o más servidores para mantener una base de datos de mapeo de
direcciones físicas a direcciones IP, para atender las solicitudes de los clientes.
• Utiliza el mismo formato de paquete utilizado por ARP.
• Existen dos tipos de paquetes: RARP request y RARP reply
• Los paquetes RARP se envía a la red como broadcast.
• Al igual que ARP, RARP no es un protocolo confiable, un cliente puede requerir solicitar
varias veces la dirección IP para obtener respuesta de algún servidor.
• Es un protocolo obsoleto.

FORMATO DEL MENSAJE

RARP utiliza el mismo formato de mensaje que ARP, tiene una longitud de 32 bits. En la figura 3
se muestran los campos del mensaje.

A continuación la descripción de cada campo:

• Hardware Type: especifica el tipo de dirección hardware o física, para ethernet se utiliza el
código 1.
• Protocol Type: especifica el tipo de dirección de protocolo, en este caso IP.
• HLEN: especifica el tamaño de la dirección física.
• PLEN: especifica el tamaño de la dirección de protocolo (lógica).

RFC 903
Carlos Aguilar Mora. 2
 • Operation: especifica si el mensaje es de solicitud o de respuesta, se utiliza el código 3
para request y 4 para reply.
• Sender HA: dirección hardware de origen.
• Sender IP: dirección lógica de origen.
• Target HA: dirección hardware de destino.
• Target IP: dirección lógica de destino.

Figura 3: Formato del mensaje RARP

FUNCIONAMIENTO

El funcionamiento de RARP se resume en los siguientes pasos:

1. Un dispositivo que no conoce su dirección IP envía un mensaje de tipo broadcast,

solicitando direccionamiento IP. En el mensaje incluye su dirección MAC.

Figura 4: RARP Request

2. Los dispositivos de la red local reciben el mensaje, el o los servidores RARP disponibles
revisan la dirección MAC en su base de datos, si la encuentran envían un mensaje unicast
con la dirección IP, al dispositivo que lo solicitó.

RFC 903
Carlos Aguilar Mora. 3
 Figura 5: RARP Reply

3. Finalmente, el dispositivo recibe la dirección IP y ya puede acceder a la red.

VENTAJAS

• En su momento permitía a terminales sin posibilidad de almacenamiento, obtener una

dirección IP de forma sencilla.

DESVENTAJAS

• Requiere la implementación de un servidor RARP en cada red local, debido a que los
mensajes enviados son de tipo broadcast los cuales no son reenviados por los routers.
• El único parámetro que asigna es la dirección IP.
• La base de datos del servidor debe ser actualizada manualmente para permitir el mapeo
de nuevas correspondencias MAC-IP

DISCUSIÓN

La implementación del protocolo ARP resultó importante para la conectividad de equipos a las
redes, pienso que fue la base para futuras implementaciones, ya que si bien este protocolo servía
para asignar una dirección IP a hosts que no disponían de almacenamiento hoy en día es
primordial la asignación de IPs a todos los host que se conectan a la red; y cobra más valor su
importancia cuando se tiene redes de gran tamaño en la que no es óptimo asignar direcciones IP
de forma manual, sino que se lo debe hacer de forma automática.

Como se puede ver RARP es un protocolo básico que solamente asignaba la dirección IP, sin
embargo es indispensable para acceder a la red y para alcanzar otras redes, la asignación de
varios parámetros de red como IP, máscara de subred, puerta de enlace, servidores DNS, entre
otros, cuyo trabajo no lo contemplaba RARP, por tal motivo y basándose en este protocolo surge
BOOTP y posteriormente DHCP solución para la asignación de parámetros de red.

Al ser RARP un protocolo obsoleto, particularmente en mi trabajo no se lo usa, ya que contamos

RFC 903
Carlos Aguilar Mora. 4
con una red de datos con 1500 usuarios aproximadamente y resultaría inadecuado tener un
protocolo de este tipo, así mismo resultaría tedioso asignar direccionamiento de forma manual, por
lo que contamos con un servidor DHCP corriendo sobre Linux en la distribución Red Hat.

CONCLUSIONES

• Debido a las limitantes que presenta, RARP es un protocolo obsoleto. Ha sido

reemplazado por protocolos que realizan su función y proporcionan parámetros
adicionales, estos son BOOTP inicialmente y en la actualidad DHCP.
• Pensar ahora utilizar RARP sería un caos para las redes, ya que debido a los avances
tecnológicos se tiene varios servicios de red, para lo cual no solamente se requiere una
dirección IP (como lo asignaba RARP), sino que se requieren muchos parámetros de red
de acuerdo a las necesidades como: máscara de subred, puerta de enlace, sufijo DNS,
servidores DNS, entre otros.
• RARP aun siendo un protocolo sencillo, se constituye en la base de protocolos como
BOOTP y DHCP, este último actualmente es ampliamente utilizado.

BIBLIOGRAFÍA

Comer, D. (2006). Internetworking with TCP/IP, principles, protocolos, and architecture. (pp.

57-67) (5ta Ed.) (Volumen 1) USA: Pearson Prentice Hall

RECURSOS WEB

http://www.ietf.org/rfc/rfc903.txt

http://www.ietf.org/rfc/rfc826.txt

RFC 903
Carlos Aguilar Mora. 5