Network Working Group T. Bradley Petición de comentarios: 2390 Avici Systems, Inc. Obsoletes: 1293 C. Brown Categoria: Borrador de estándar Consultant A. Malis Ascend Communications, Inc. September 1998 Traducción: Juan de la Fuente Costa Protocolo de Resolución Inversa de Direcciones Estado de este documento Este documento especifica el seguimiento del protocolo para la comunidad de Internet, solicitando sugerencias y criticas con el fin de mejorarlo. Para ver el estado de estandarización de este protocolo consultar la edición actual de "Protocolos Estándares Oficiales de Internet"(STD 1). La distribución de este documento es ilimitada. Nota de Copyright Copyright (C) The Internet Society (1998). Todos los derechos reservados. 2. Resumen Este documento describe métodos adiciones a ARP que permitirán a una estación de trabajo consultar la dirección física de una determinada dirección. Más concretamente, en las estaciones Frame Relay que pueden tener un Identificador de la conexión de enlace de datos (DLCI), el equivalente en Frame Relay a las direcciones físicas, asociadas con un Circuito Virtual Permanente (PVC) establecido, pero que desconoce la dirección del protocolo de la estación que está en el otro lado de la conexión. También se podrá aplicar a otras redes bajo circunstancias similares. Este documento reemplaza el RFC 1293. Los cambios realizados en el RFC 1293 son cambios de menor importancia realizados para formalizar el lenguaje, añadir un ejemplo en la sección 7.2, e incorporar una nueva sección de seguridad. 3. Convenios Las palabras TENER, NO TENER, REQUISITO, PODER, NO PODER, DEBER, NO DEBER, RECOMENDADO, PUEDE y OPCIONAL, cuando aparecen en este documento tienen que interpretarse como se describe en [5]. Bradley, et. al. Borrador de estándar [Página 1] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 4. Introducción Este documento usará mucho Frame Relay como ejemplo de la utilidad del Protocolo de Resolución Inversa de Direcciones (InARP). Sin embargo, InARP no esta pensado para ser usado exclusivamente en Frame Relay. InARP puede ser usado en cualquier red que proporciona direcciones hardware sin indicar la correspondiente dirección de protocolo. 5. Motivación La motivación para el desarrollo del ARP Inverso es el resultado del deseo de hacer la resolución dinámica de direcciones en redes Frame Relay posible y eficaz. Los circuitos virtuales permanentes (PVC) y eventualmente los circuitos virtuales en entornos de Switch (SVCs) son identificados mediante Identificadores de la conexión de enlace de datos (DLCI). Dichos (DLCI) definen una única conexión virtual a través de la red de área extensa (WAN) y puede ser el equivalente en Frame Relay a una dirección física. Periódicamente, a través del intercambio de mensajes de señalización, una red propaga, la existencia de un circuito virtual con su correspondiente DLCI. Desafortunadamente, la dirección de protocolo no esta incluida en el mensaje. La estación receptora del mensaje ha de aprender la nueva conexión, pero no será capaz de referenciar la dirección de la otra parte. Sin un nueva configuración o un mecanismo que permita descubrir la dirección física de la otra parte, este nuevo circuito virtual no se podrá utilizar. Se valoraron otros métodos de resolución para resolver esta situación, pero fueron descartados. ARP Reverso [4], por ejemplo, parecía un buen candidato, pero la respuesta a una petición de dirección física que se obtenía es la dirección de la estación que realiza la consulta, y no a la que se consulta. Los mecanismos específicos a nivel IP están limitados ya que no permiten la resolución de otros protocolos distintos de IP. Por esta razón se amplió el uso del protocolo ARP. El Protocolo de Resolución Inversa (InARP) permitirá a una estación Frame Relay descubrir la dirección física de la estación asociada al circuito virtual. Es más eficiente que enviar mensajes ARP en cada VC para cada dirección física que el sistema quiera conocer y más flexible que confiar en una configuración estática. 6. Formato de los Paquetes ARP Inverso es una extensión del ARP existente . Por lo tanto, tiene el mismo formato que ARP estándar. Bradley, et. al. Borrador de estándar [Página 2] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 ar$hrd 16 bits Tipo fisico. ar$pro 16 bits Tipo de protocolo. ar$hln 8 bits Byte de longitud para cada dirección física (n) ar$pln 8 bits Byte de longitud para cada dirección de protocolo (m) ar$op 16 bits Código de operacion. ar$sha n bytes Dirección física de origen ar$spa m bytes Dirección de protocolo del origen ar$tha n bytes Dirección física destino ar$tpa m bytes Dirección de protocolo del destino Los posibles valores de para direcciones físicas y tipos de protocolo son los mismas que para ARP y se encuentran reflejados en los correspondientes RFCs [2]. La longitud de la dirección física y de protocolo dependen del entorno en el que esté aplicándose InARP. Por ejemplo, si IP esta corriendo en un entorno de Frame Relay, la longitud de la dirección física sera 2, 3 ó 4 y la longitud para la dirección del protocolo será 4. El código de operación indica el tipo de mensaje, petición o respuesta. Petición InARP = 8 Respuesta InARP = 9 Estos valores se seleccionaron de forma que no entraran en conflicto con otras extensiones ARP. 7. Funcionamiento del Protocolo InARP básico opera esencialmente como ARP con la excepción de que InARP no realiza difusiones de las peticiones. Dichas difusiones no se realizan porque la dirección física de la estacion destino ya se conoce. Cuando un interfaz con soporte InARP se activa, debería iniciar el protocolo InARP y realizar peticiones InARP para cada PVC que tenga el protocolo InARP activo. Para ello, una estación que consulte simplemente realiza una petición indicando en ella su dirección física de origen, dirección de protocolo de origen, y la dirección física de destino. A continuación, completa con ceros el campo de direccion de protocolo destino y la envía directamente a la estación destino. Una vez recibida una petición InARP, la estación ha de mapear la Bradley, et. al. Borrador de estándar [Página 3] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 dirección física y de protocolo de la estación que realiza la petición en su cache ARP y así con todas las peticiones ARP. Sin embargo, con otras peticiones ARP, la estación receptora asumira que cualquier petición InARP que reciba estará destinada para ella. Para cada petición InARP, la estación receptora deberá construir una respuesta correcta usando las direcciones de origen de la petición así como la dirección destino de la respuesta. Si la estación es incapaz o no puede gestionar la respuesta, la ignorará. Cuanto la estación que realiza la petición recibe la respuesta InARP, podrá completar la entrada en la tabla ARP y usar la información que aporta dicha dirección. Nota: como con ARP, la información aprendida a través de InARP puede ser fechada o invalidada bajo ciertas circunstancias. 7.1. Funcionamiento con Hosts que tienen múltiples direcciones. En este contexto, un host con múltiples direcciones se refiere a un host que tiene múltiples direcciones de protocolo asignadas a un solo interfaz. Si dicha estación recibe una petición InARP, ha de escoger con que dirección responder. Para realizar dicha elección, la estación receptora consultará la dirección de protocolo de la estación que realizó la petición, y a continuación responderá con la dirección de protocolo correspondiente a la red de la petición. Por ejemplo, si la estación que realiza la petición está consultando por una dirección IP, la respuesta del host con múltiples direcciones debera ser una IP que pertenezca a la misma subred que la estación que realizó la petición. Si la estación no tiene una dirección apropiada para responder a la petición no deberá responder. En el ejemplo de IP, si la estación receptora no tiene dirección IP asignada en la interfaz que forma parte de la subred consultada, no deberá responder a la petición. Un host con múltiples direcciones deberá enviar una petición InARP por cada una de las direcciones definidas en la interfaz dada. Se deberá de tener en cuenta, sin embargo, que la parte receptora contestará a alguna o a ninguna de las peticiones en función de su configuración. 7.2. Funcionamiento del protocolo en entorno Frame Relay. Un entorno en el que se puede hacer uso de la resolución inversa de ARP son las interfaces Frame Relay que soportan señalización de DLCI a través de la interfaz de gestión de enlace. Una estación equipada con InARP conectada a dicha interfaz podrá construir peticiones InARP y enviarlas al nuevo circuito virtual. Si la otra parte de la comunicacion soporta InARP, devolverá una respuesta indicando la Bradley, et. al. Borrador de estándar [Página 4] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 dirección de protocolo requerida. En un entorno de Frame Relay, los paquetes InARP son encapsulados usando el formato NLPID/SNAP definido en [3] que indica el protocolo ARP. Específicamente, la encapsulación del paquete es como sigue: +----------+----------+ | Q.922 address | +----------+----------+ |ctrl 0x03 | pad 00 | +----------+----------+ |nlpid 0x80| oui 0x00 | +----------+ + | oui (cont) 0x00 00 | +----------+----------+ | pid 0x08 06 | +----------+----------+ | . | | . | El formato de la petición InARP se describe a continuación: ar$hrd - 0x000F el valor asignado a Frame Relay ar$pro - tipo de protocolo que se está buscando (x.ej. IP = 0x0800) ar$hln - 2,3, o 4 bytes de longitud de la dirección ar$pln - longitud del byte de la dirección del protocolo que se está buscando (para IP = 4) ar$op - 8; Petición InARP ar$sha - Q.922 [6] dirección de la estación que realiza la petición ar$spa - dirección del protocolo de la estación que realiza la petición ar$tha - Q.922 dirección del nuevo circuito virtual anunciado ar$tpa - 0; Esto es lo que se pide La respuesta InARP será completada de forma similar ar$hrd - 0x000F el valor asignado al Frame Relay ar$pro - tipo de protocolo que se está buscando (x.ej. IP = 0x0800) ar$hln - 2,3, o 4 bytes de longitud de la dirección ar$pln - longitud del byte de la dirección del protocolo que se está buscando (para IP = 4) ar$op - 9; Respuesta InARP ar$sha - Q.922 dirección de la estación que responde a la petición ar$spa - dirección del protocolo de la estación que recibe la petición Bradley, et. al. Borrador de estándar [Página 5] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 ar$tha - Q.922 dirección de la estación que realiza la petición ar$tpa - dirección del protocolo de la estación que realiza la petición Señalar aqui que las direcciones Q.922 especificadas tienen los bits C/R, FECN, BECN y DE a cero. Los Procedimientos para usar InARP sobre redes Frame Relay son como siguen: Como los DLCIs en la mayoría de las redes Frame Relay tiene significado local, una estación final no tendra asignada especificamente un DLCI. Por lo tanto, dicha estación no tendrá una dirección para incluir en las peticiones o respuestas InARP. Afortunadamente, las redes Frame Relay proporcionan un metodo para obtener los DLCIs correctos. La solución propuesta para el direccionamiento local en redes Frame Relay a continuación funcionara igualmente bien en aquellas redes en las que los DLCIs tengan significado global. Los DLCI transportados en las cabeceras Frame Relay son modificados cuando atraviesan las redes. Cuando un paquete alcanza su destino, el DLCI se modificará de forma que el valor, desde el punto de vista de la estación receptora corresponda a la estación de origen. Por ejemplo, en la figura 1 a continuación, si la estación A envia un mensaje a la estación B, indicará el DLCI 50 en la cabecera Frame Relay. Cuando la estación B reciba dicho mensaje, sin embargo, el DLCI habrá sido modificado por la red y aparecerá en B como DLCI 70. Bradley, et. al. Borrador de estándar [Página 6] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 ~~~~~~~~~~~~~~~ ( ) +-----+ ( ) +-----+ | |-50------(--------------------)---------70-| | | A | ( ) | B | | |-60-----(---------+ ) | | +-----+ ( | ) +-----+ ( | ) ( | ) <--- Red Frame Relay ~~~~~~~~~~~~~~~~ 80 | +-----+ | | | C | | | +-----+ Figura 1 Las líneas entrantes a las estaciones representan las conexiones de enlace de datos (DLCs). Los números indican los DLCI locales asociados con cada conexión. Tabla de correspondencia DLCI a Q.922 para la figura 1 DLCI (decimal) Dirección Q.922 (hex) 50 0x0C21 60 0X0CC1 70 0X1061 80 0X1401 Para una descripción con propiedad de la correlación entre DLCI y direcciones Q.922 [6], el lector deberá consultar las especificaciones. Se incluye un resumen de la correlación aqui por conveniencia. La traducción de direcciones entre DLCI y Q.922 está basada en una dirección de longitud dos bytes usando la codificación Q.922. El formato es: 8 7 6 5 4 3 2 1 +------------------------+---+--+ | DLCI (orden supe) |C/R|EA| +--------------+----+----+---+--+ | DLCI(+abajo) |FECN|BECN|DE |EA| +--------------+----+----+---+--+ Para InARP, se asume que los bits FECN, BECN, C/R y DE toman valor cero. Cuando un mensaje InARP alcanza un destino, todas las direcciones físicas serán invalidas. La dirección encontrada en la cabecera de la trama será, sin embargo, correcta. Aunque este comportamiento va en contra de la teoría de capas, Frame Relay puede Bradley, et. al. Borrador de estándar [Página 7] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 usar la dirección de la cabecera como dirección física de origen. También cabe indicar que la dirección física destino, en consulta y respuesta InARP, puede ser igualmente invalida. Esto no debería causar problemas ya que InARP no confia en estos campos y de hecho, una implementación debe de completar con ceros o ignorar completamente el campo de la dirección física destino. Usando la figura 1 como ejemplo, la estación A puede usar Arp Inverso para descubrir las direcciones de protocolo asociadas a la estación con DLCI 50. Las peticiones de ARP Inverso serán de la siguiente forma: Peticiones InARP desde A (DLCI 50) ar$op 8 (Petición InARP) ar$sha desconocido ar$spa pA ar$tha 0x0C21 (DLCI 50) ar$tpa desconocido Cuando la estación B recibe este paquete, modificará la dirección física de origen con la dirección Q.922 de la cabecera Frame Relay. De esta forma, la petición InARP será: ar$op 8 (Petición InARP) ar$sha 0x1061 (DLCI 70) ar$spa pA ar$tha 0x0C21 (DLCI 50) ar$tpa desconocido. La estación B formateará la respuesta Inversa ARP y la enviará a la estación A de la forma: ar$op 9 (Respuesta InARP) ar$sha desconocido ar$spa pB ar$tha 0x1061 (DLCI 70) ar$tpa pA La dirección física de origen es desconocida y cuando se recibe la respuesta, la estación A extraerá la dirección de la cabecera Frame Relay y la colocará en el campo de dirección física origen. Por lo tanto, la respuesta se convertirá en: ar$op 9 (Respuesta InARP) ar$sha 0x0C21 (DLCI 50) ar$spa pB ar$tha 0x1061 (DLCI 70) ar$tpa pA Bradley, et. al. Borrador de estándar [Página 8] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 Esto significa que el interfaz Frame Relay únicamente interviene procesando los paquetes entrantes. Se recomienda consultar [3] para una descripción de procesos similares en el uso de ARP [1] y RARP [4] en Frame Relay. 8. Consideraciones de seguridad Este documendo especifica una extensión en las funciones de la familia de protocolos ARP, y está sujeta a las mismas consideraciones de seguridad que afectan a ARP y a protocolos similares de resolución de direcciones. Como la autenticación no es parte de ARP, hay problemas conocidos relacionados con su uso (p. e., suplantación de un host). No se han añadido mecanismos de seguridad adicionales a la familia de protocolos ARP en este documento. 9. Referencias [1] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993. [4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Information technology - Telecommunications and Information Exchange between systems - Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1992. 10. Dirección de los Autores Terry Bradley Avici Systems, Inc. 12 Elizabeth Drive Chelmsford, MA 01824 Teléfono: (978) 250-3344 Bradley, et. al. Borrador de estándar [Página 9] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 Correo Electrónico: tbradley@avici.com Caralyn Brown Consultant Correo Electrónico: cbrown@juno.com Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 Teléfono: (978) 952-7414 Correo Electrónico: malis@ascend.com 11. Declaración Completa de Copyright Copyright (C) The Internet Society (2001). Todos los derechos reservados. Este documento y sus traducciones pueden ser copiados y facilitadas a otros, y los trabajos derivados que lo comentan o explican o que están incluidos en él, pueden ser copiados, publicados y distribuidos, enteros o en parte, sin restricción de ningún tipo, siempre que incluyan este párrafo y la nota de copyright arriba expuesta en todas esas copias y trabajos derivados. Sin embargo, este documento en sí no debe ser modificado de ninguna forma, como por ejemplo eliminando la nota de copyright o referencias a la 'Internet Society' u otras organizaciones de Internet, excepto cuando sea necesario para propósitos para el desarrollo de estándares de Internet, en cuyo caso se seguirán los procedimientos para copyrights definidos en el proceso de Estándares de Internet, o con motivo de su traducción a otros idiomas aparte del Inglés. Los permisos limitados concedidos anteriormente son perpetuos y no serán revocados por la 'Internet Society' o sus sucesores o cesionarios. Este documento y la información en él contenida se proporciona en su forma "tal como se encuentra" y LA 'INTERNET SOCIETY' Y EL GRUPO DE TRABAJO DE INGENIERÍA DE INTERNET RECHAZAN CUALQUIER GARANTÍA, EXPRESAS O IMPLÍCITAS, INCLUYENDO PERO NO LIMITADAS A, CUALQUIER GARANTÍA DE QUE EL USO DE LA INFORMACIÓN AQUÍ EXPUESTA NO INFRINGIRÁ NINGUNO DERECHO O GARANTÍAS IMPLICITAS DE COMERCIALIZACIÓN O Bradley, et. al. Borrador de estándar [Página 10] RFC 2390 Protocolo de Resolución Inversa de Direcciones Sept. 1998 IDONEIDAD PARA UN PROPÓSITO PARTICULAR. Bradley, et. al. Borrador de estándar [Página 11]