Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

Desarrollo de una Herramienta Software para el Acceso a Redes TCP/IP a través de la Red Telefónica Conmutada

Última Actualización: 30 de Junio de 1.996 - Domingo

Capítulo 4:
El Módulo ARP

El módulo ARP (Address Resolution Protocol) es el encargado de realizar las traducciones de direcciones lógicas a direcciones físicas. Esto es, traducir las direcciones IP utilizadas en las capas superiores a direcciones de dispositivos dependientes del hardware subyacente. Este hardware puede estar constituido por una red Ethernet, FDDI, un sistema AX.25, etc., cada uno de los cuales tiene sus propias características de direccionamiento. Este nivel, por tanto, aisla a las capas superiores (en especial a la capa IP) de los diferentes esquemas de nombramiento posibles a nivel físico.

Cuando un nodo de la red desea enviar un paquete a otra máquina debe averiguar su dirección física. La máquina fuente conoce sus propias direcciones IP y física (las direcciones de sus interfaces de red), pero toda la información que dispone sobre la máquina remota es su dirección IP. Para conocer la dirección física equivalente se envía un mensaje ARP Broadcast (en las redes sin la opción de Broadcast se suele confiar la tarea de resolver direcciones a un nodo conocido por los demás). Este mensaje lo reciben todas las máquinas de la red, pero sólo contesta la máquina solicitada. Este proceso, para el caso especial de una red Ethernet, se describe en [RFC826].

Existen situaciones, no obstante, en los que una máquina ni siquiera conoce su propia dirección IP. Es el caso, por ejemplo, de estaciones sin disco (en particular, terminales X-Window). En esta situación todas las estaciones son idénticas y ejecutan el mismo software (almacenado en una ROM o EPROM). La única diferencia entre ellas es la dirección física de su interfaz de red. Dado que para comunicarse con otros nodos necesitan conocer su propia dirección IP, realizan un proceso RARP (Reverse Address Resolution Protocol). Este consiste en el envío de un paquete RARP Broadcast. Este paquete es recibido, en particular, por una máquina (un servidor) que contiene una tabla de traducción entre direcciones físicas y direcciones IP. Dicha máquina envía a la primera una respuesta indicando qué dirección IP le corresponde. El procedimiento se describe en [RFC903].

Existen, todavía, dos extensiones al protocolo ARP a tener en cuenta. El primero [RFC1293] describe un procedimiento por medio del cual un sistema dado puede averiguar la o las direcciones del nodo situado al otro extremo de un enlace punto a punto. Ello resulta especialmente importante, por ejemplo, en redes de circuitos virtuales como ATM y Frame Relay. La segunda extensión [RFC1868] define un algoritmo a través del que un nodo concreto puede anunciar su retirada de la red. Ello es muy útil en accesos PROXY donde las direcciones asignadas a los nodos son dinámicas. Recientemente se ha definido una extensión al protocolo RARP [RFC1931] que permite la asignación de direcciones dinámicas a estaciones sin disco. Su funcionamiento es muy similar al protocolo DHCP [RFC1541] (Dynamic Host Configuration Protocol).


Interfaz


PROC_ARP_BC

Este proceso se encarga de inicializar y finalizar el módulo ARP. Los mensajes admitidos son MSG_INIT y MSG_QUIT. Los campos de información son ignorados. 


PROC_ARP_SUP

Este proceso es el encargado de realizar la traducción entre direcciones IP y direcciones físicas del dispositivo. Se sitúa entre la capa IP y el nivel físico. Admite mensajes MSG_MBUF con los campos siguientes:

Campo1: Ignorado
Campo2: Nombre del canal físico a través del cual se envía el datagrama
Campo3: Dirección IP destino

En la implementación actual este proceso envía el mensaje directamente a la capa física, sin efectuar ninguna manipulación previa. 


PROC_ARP_INF

Este proceso no es utilizado, dadas las características de la implementación efectuada.


Implementación

Este Proyecto Fin de Carrera tiene como objetivo la implementación de la torre de protocolos IP/UDP/TCP para su funcionamiento en conexiones punto a punto, no en redes Broadcast. Debido a ello no se necesita la traducción de direcciones. La gestión explícita de direcciones dinámicas se realiza a través de las facilidades proporcionadas por el protocolo PPP (Point-to-Point Protocol). Se ha elegido, no obstante, el implementar un nivel ARP rudimentario para facilitar la actualización del sistema a redes como la de RadioPaquete, utilizada por los Radioaficionados de todo el mundo (AX.25). Esta red es del tipo Broadcast y cada estación tiene una dirección física asignada que coincide con el indicativo de su operador.


Bibliografía


[KISS]      "Proposed "Raw" (aka "KISS") TNC Functional Spec"
            Phil Karn, KA9Q
            Mike Cheppionis, K3MC
            6 August 1986

[MACAX25]   "MacAX25 Design Speficications"
            Tim Hayes, N2KBG
            Abril 1.995

[RFC826]    RFC 826: "An Ethernet Address Resolution Protocol or
            Converting Network Protocol Addresses to 48.bit
            Ethernet Address for Transmission on Ethernet
            Hardware"
            David C. Plummer
            Noviembre 1.982

[RFC903]    RFC 903: "A Reverse Address Resolution Protocol"
            Ross Finlayson
            Timothy Mann
            Jeffrey Mogul
            Marvin Theimer
            Junio 1.984

[RFC1122]   RFC1122: "Requirements for Internet Hosts --
            Communication Layers"
            Robert Braden
            Octubre 1.989

[RFC1293]   RFC 1293: "Inverse Address Resolution Protocol"
            T. Bradley
            C. Brown
            Enero 1.992

[RFC1541]   RFC1541: "Dynamic Host Configuration Protocol"
            R. Droms
            Octubre 1993

[RFC1868]   RFC 1868: "ARP Extension - UNARP"
            G. Malkin
            Noviembre 1.995

[RFC1931]   RFC 1931: "Dynamic RARP Extensions for Automatic
            Network Address Acquisition"
            D. Brownell
            Abril 1996

[SMACK]     "The SMACK Protocol"
            Jan Schiefer, DL5UE
            Dieter Deyke, DK5SG/N0PRA
            27 de Febrero de 1.992
            Original en Alemán. Traducción al Inglés por Mike
            Chace, G6DHU, en Febrero de 1.993

Python Zope ©1996 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS