Network Working Group Finlayson, Mann, Mogul, Theimer Request for Comments: 903 Stanford University Un Protocolo para Resolución Inversa de Dirección Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer Computer Science Department Stanford University Junio 1984 Estado de este Memorándum Este RFC sugiere un método para estaciones de trabajo para buscar dinámicamente sus direcciones de protocolo (ej: su Dirección Internet), cuando ellas conocen sólo su dirección de hardware (ej: su dirección de red de conexión física). Este RFC especifica un protocolo propuesto por la comunidad ARPA Internet, y solicita discusión y sugerencias para mejoras. I. Introducción Los hosts de red como una estación de trabajo bajo disco frecuentemente no conocen sus direcciones de protocolo cuando arrancan; muchas veces conocen sólo sus direcciones de interfases de hardware. Para comunicarse usando protocolos de nivel-superior como IP, deben descubrir su dirección de protocolo desde algúnn origen externo. Nuestro problema es que no es un mecanismo estándar para hacer esto. El "Protocolo de Resolución de Dirección" de Plummer (ARP) [1] está diseñado para resolver un problema complementario, resolviendo una dirección de hardware del host dando su dirección de protocolo. Este RFC propone un "Protocolo de Resolución Inversa de Dirección". Como con ARP, nosotros asumimos un medio de emisión, como es Ethernet. II. Consideraciones de diseño Las siguientes consideraciones guían nuestro diseño del protocolo RARP A. ARP y RARP son operaciones diferentes. ARP asume que cualquier host conoce el mapeo entre su propias dirección hardware y su(s) dirección(es) de protocolo. La información reunida sobre otros host es acumulada en una pequeña cache. Todos los hosts están en el mismo estado; allí no hay distinciones entre clientes y servidores. Por otra parte, RARP requiere uno o más servidores para mantener una Finlayson, Mann, Mogul, Theimer [Página 1] RFC 903 Junio 1984 base de datos de mapeos desde dirección de hardware a dirección de protocolo y para responder a las solicitudes de los clientes. B. Como mencionamos, RARP requiere que los hosts servidores mantengan una gran base de datos. Esto es indeseable y en algunos casos imposible mantener como una base de datos en el kernel de un sistema operativo del host. Así, muchas implementaciones requerirán alguna forma de interacción con un programa fuera del kernel. C. Son importantes la facilidad de implementación y el impacto mínimo en el software de host existente. Puede ser un error desarrollar un protocolo que requiera modificaciones a cada software de host, participe o no de este. D. Esto es deseable para permitir la posibilidad de compartir código con software existente, minimizar gastos y costos de desarrollo. III. El protocolo propuesto Proponemos que RARP sea especificado como un protocolo separado en el nivel conexión-de-datos. Por ejemplo, si el medio usado es Ethernet, entonces los paquetes RARP tendrán un Ethertype (todavía por ser asignado) diferente que el de ARP. Esto reconoce que ARP y RARP son dos operaciones fundamentalmente diferentes, no soportados igualmente por todos los hosts. El impacto en sistemas existentes es minimizado; existiendo servidores ARP que no serán confundidos por paquetes RARP. Esto hace a RARP una facilidad general que puede ser usada para mapeos de direcciones hardware a cualquier dirección de protocolo de nivel superior. Este enfoque hace sencilla la implementación para los clientes RARP, pero pone mayores dificultades para los servidores RARP. Sin embargo, estas dificultades no deberían ser insuperables, como se muestra en el Apéndice A, donde esquematizamos dos posibles implementaciones para 4.2BSD Unix. RARP usa el mismo formato de paquete que es usado por ARP, a saber: ar$hrd (espacio de dirección de hardware) - 16 bits ar$pro (espacio de dirección de protocolo) - 16 bits ar$hln (longitud dirección de hardware) - 8 bits ar$pln (longitud dirección de protocolo) - 8 bits ar$op (código de operación) - 16 bits Finlayson, Mann, Mogul, Theimer [Página 2] RFC 903 Junio 1984 ar$sha (dirección hardware de origen) - n bytes, donde n es tomado del campo ar$hln. ar$spa (dirección protocolo de origen) - m bytes, donde m es tomado del campo ar$pln. ar$tha (dirección hardware de destino) - n bytes ar$tpa (dirección protocolo de destino) - m bytes ar$hrd, ar$pro, ar$hln y ar$pln son lo mismo que en ARP (ver [1]). Suponga, por ejemplo, que las direcciones "hardware" son direcciones Ethernet de 48-bits, y las direcciones de "protocolo" son Direcciones Internet de 32-bits. Nosotros queremos determinar las Direcciones Internet correspondientes a las direcciones Ethernet conocidas. Entonces, en cada paquete RARP, ar$hrd = 1 (Ethernet), ar$pro = 2048 decimal (el Ethertype de los paquetes IP), ar$hln = 6, y ar$pln = 4. Hay dos opcodes: 3 ("solicitud inversa") y 4 ("respuesta inversa"). Un opcode de 1 o 2 tiene el mismo significado que en [1]; los paquetes con estos opcodes pueden ser pasados al código ARP regular. Un paquete con cualquier otro opcode está indefinido. Como en ARP, estos no son paquetes "no encontrados" o "error", desde muchos servidores RARP están libres de responder a una solicitud. El emisor de un paquete de solicitud RARP debería caducar si este no recibe una respuesta para esta solicitud dentro de una tiempo razonable. Los campos ar$sha, ar$spa, ar&tha y ar$tpa del paquete RARP son interpretados como sigue: Cuando el opcode es 3 ("solicitud inversa"): ar$sha es la dirección de hardware del emisor del paquete. ar$spa está indefinido. ar$tha es la dirección de hardware de "destino" . En el caso donde el emisor desee determinar su propia dirección de protocolo, esta, como ar$sha, será la dirección de hardware del emisor. ar$tpa está indefinido. Cuando el opcode es 4 ("respuesta inversa"): ar$sha es la dirección de hardware del que responde (el emisor del Finlayson, Mann, Mogul, Theimer [Página 3] RFC 903 Junio 1984 paquete de respuesta). ar$spa es la dirección de protocolo del que responde (ver la nota a continuación). ar$tha es la dirección de hardware del destino, y debería ser la misma que fue dada en la solicitud. ar$tpa es la dirección de protocolo del destino, que es, la dirección deseada. Note que el requisito que paquetes con ar$spa en opcode 4 sean llenados con el protocolo del que responde es puramente por conveniencia. Por ejemplo, si un sistema estaba usando ambos ARP y RARP, entonces la inclusión del par dirección válida protocolo- hardware (ar$spa, ar$sha) puede eliminar la necesidad para una solicitud ARP subsecuente. IV. Referencias [1] Plummer, D., "Un Protocolo de Resolución de Dirección Ethernet" (An Ethernet Address Resolution Protocol), RFC 826, MIT-LCS, Noviembre 1982. Apéndice A. Dos ejemplos de implementaciones para 4.2BSD Unix La implementación siguiente esquematiza en resumen dos diferentes enfoques para hacer un servidor RARP bajo 4.2BSD. A. Proveer acceso a paquetes de nivel datos-conexión fuera del kernel. El servidor RARP está implementado completamente fuera del kernel e interactúa con el kernel sólo para recibir y enviar paquetes RARP. El kernel tiene que ser modificado para proveer el acceso apropiado para estos paquetes; actualmente el kernel 4.2 permite acceso sólo a paquetes IP. Un mecanismo existente que provee esta capacidad es el seudo controlador "filtro-de-paquete" CMU. Este ha sido usado exitosamente en CMU y Stanford para implementar tipos similares de servidores de red "nivel-de-usuario". B. Mantener una cache de entradas de base de datos dentro del kernel. La base de datos del servidor RARP completa es mantenida fuera del kernel por un proceso de usuario. El mismo servidor RARP está implementado directamente en el kernel y emplea un peque¤o cache de entradas de base de datos para sus respuestas. Esta cache puede ser la misma que es usada para reenviar ARP. La cache toma entradas desde la base de datos RARP actual por medio de dos nuevos ioctls. (Estos son como SIOCIFADDR, en que ellos no son Finlayson, Mann, Mogul, Theimer [Página 4] RFC 903 Junio 1984 realmente asociados con un socket específico). Uno significa: "dormir hasta que una traducción sea hecha, entonces pasar la solicitud fuera, al proceso de usuario"; el otro significado: "ingresar esta traducción dentro de la tabla del kernel". Así, cuando el kernel no puede encontrar una entrada en la cache, pone la solicitud en una cola (global) y entonces hace una pausa (wakeup()) . La implementación del primer ioctl es para dormir (sleep()) y entonces quita el primer ítem de esta cola y lo devuelve al proceso de usuario. Desde el kernel no puede esperar en nivel interrupción hasta que el proceso de usuario responda, puede dejarlo (y asumir que el host solicitante retransmitirá el paquete de solicitud después de unos segundos) o si el segundo ioctl pasa una copia de la solicitud devuelta al kernel, formula y envía una respuesta en este momento. Traducción al castellano: A.J. Waisbrot (2002) Finlayson, Mann, Mogul, Theimer [Página 5]