Network Working Group Jeffrey Mogul Request for Comments: 922 Computer Science Department Stanford University Octubre de 1984 DIFUSION DE DATAGRAMAS DE INTERNET EN PRESENCIA DE SUBREDES (Traducción al castellano: Febrero de 2001) (Por Domingo Sánchez Ruiz ) Estado de este memorándum Se proponen reglas simples para la difusión ("broadcasting") de datagramas de Internet en redes locales que soporten difusión, para el direccionamiento de las difusiones y sobre cómo las pasarelas ("gateways") deben tratarlas. Este RFC sugiere un protocolo, propuesto para la comunidad de ARPA- Internet, y solicita discusiones y sugerencias para su mejora. La distribución de este memorándum no está limitada. Agradecimientos Esta propuesta es el resultado de discusiones mantenidas con otras personas, principalmente con J. Noel Chiappa y Christopher A. Kent, que me informaron acerca de importantes referencias. 1. Introducción El uso de las difusiones, especialmente en redes de área local de alta velocidad, constituye una buena base para muchas aplicaciones. Como la difusión no queda cubierta en la especificación básica de IP [12], no existe un acuerdo unánime acerca de cómo hacerlas, y, por tanto, los diseñadores de protocolos no han hecho uso de ellas. (El tema ha sido tratado con anterioridad, e.g. [6], pero no ha alcanzado la categoría de estándar). Aquí se considera sólamente el caso de difusiones de datagramas no fiables, desordenados y posiblemente duplicados (para una discusión de difusiones TCP, ver [10]). Aunque no sean fiables y tengan límites, las difusiones de datagramas son bastante útiles [1]. Se asumirá que la capa de enlace de datos de la red local dispone de un mecanismo eficiente de difusión. La mayoría de la redes comunes de área local incluyen mecanismos de difusión; por ejemplo, Ethernet [7, 5], ChaosNet [9], redes de tipo "token ring" [2], etc. No se asumirá, sin embargo, que la entrega de las difusiones sea fiable. (Se debería considerar el proporcionar un protocolo de difusión fiable en una capa de nivel más alto que IP). Garantizar la Mogul [Pág. 1] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 entrega de las difusiones es algo bastante costoso; en su lugar, asumimos que un 'host' recibirá la mayoría de las difusiones que se envíen. Es importante evitar un uso excesivo de las difusiones; como cada 'host' de la red debe dedicar un mínimo de esfuerzo en cada difusión, éstas son costosas. La difusión de un datagrama impone un coste en cada 'host' que tenga que escucharlo. Por tanto, la difusión no debería utilizarse indiscriminadamente, sino únicamente cuando constituya la mejor solución a un problema. 2. Terminología Como la difusión depende de la capa de enlace de datos específicamente utilizada en la red local hay que discutirla haciendo referencia tanto a las redes físicas como a las lógicas. Desde el punto de vista de un 'host' enviando o reenviando una difusión, los términos que se utilizarán al referirse a las redes físicas son: Red física local El enlace físico al cuál el 'host' está conectado. Red física remota Una red física que está separada del 'host' por al menos una pasarela. Colección de redes físicas Un conjunto de redes conectadas (transitivamente) por pasarelas. El mundo IP incluye varios tipos de redes lógicas. Para evitar la ambigüedad, se utilizarán los siguientes términos: Internet La colección DARPA Internet de redes IP. Red IP Una red o una colección de varias redes físicas que tienen un número de red IP específico. Subred Un miembro único de la colección de redes físicas que conforman una red IP. Las direcciones de 'host' dentro de una subred dada comparten el número de red IP con los 'hosts' de todo el resto de Mogul [Pág. 2] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 subredes de esa red IP, pero la parte local de la dirección se divide en los campos de número de subred y de número de 'host' para indicar en qué subred está un determinado 'host'. No se asume ninguna división concreta de la parte local de la dirección; esto podría variar según la red considerada. La introducción de un nivel de subred en la jerarquía de direccionamiento está en desacuerdo con la especificación IP [12], pero como el uso de subredes direccionables prolifera resulta evidente que un esquema de difusión debería dar soporte a la división en subredes. Para saber más sobre subredes, véase [8]. En este artículo, el término "dirección de 'host'" se referirá al campo de dirección de 'host' de una red IP subdividida en subredes sin incluir el número de subred, o al campo con la parte de 'host' en otro caso. Una red IP puede consistir en una red física única o en una colección de subredes;esto no debería importar desde el punto de vista de un 'host' de otra red IP. 3. ¿ Por qué utilizar difusiones? Las difusiones son útiles cuando un 'host' necesita encontrar información sin saber exactamente qué otro 'host' se la puede proporcionar, o cuando un 'host' quiere proporcionar información a un conjunto grande de 'hosts' de una forma ocasional. Cuando un 'host' necesita información de la que podría disponer uno o más de sus vecinos, el 'host' podría tener una lista de vecinos a los que preguntar o sondear a todos sus vecinos hasta que uno de ellos respondiera. El uso de listas prefijadas crea un evidente problema de gestión de red (un listado a priori resulta poco flexible). Por otra parte, preguntar a todos los vecinos resulta lento si se deben generar todas las direcciones de 'host' factibles y probar con cada 'host' hasta que uno responda correctamente. En ARPANET, por ejemplo, hay aproximadamente 65 mil números de red posibles. La mayoría de las implementaciones han utilizado listas prefijadas (por ejemplo, direcciones de las pasarelas "primarias"). Afortunadamente, la difusión proporciona a un 'host' una forma rápida y simple de llegar a todos sus vecinos. Un 'host' podría también utilizar la difusión para proporcionar a todos sus vecinos una determinada información; por ejemplo, una pasarela podría anunciar su presencia a otras pasarelas. Una forma de ver la difusión es como un substituto imperfecto del multienvío ('multicasting'), el envío de mensajes a un subconjunto de 'hosts' de una red. En la práctica, se utilizan habitualmente difusiones cuando lo que se desea realmente son multienvíos; los Mogul [Pág. 3] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 paquetes se difunden a nivel físico, pero los programas de filtrado en los 'hosts' receptores causan el efecto de multienvío. Para más ejemplos de aplicaciones de difusión, véase [1, 3]. 4. Clases de difusión Hay varias clases de difusión de IP: - Difusión de datagramas con destino único en la red física local: Un datagrama está destinado a un 'host' IP específico, pero el 'host' emisor lo difunde a nivel de la capa de enlace, quizás para evitar el tener que encaminarlo. Como esto no es una difusión de IP, la capa IP no está implicada, exceptuando el que un 'host' debe descartar los datagramas no destinados a él sin llegar a notarse (por ejemplo, imprimiendo un mensaje de error). - Difusión a todos los 'hosts' de una red física local: Un valor especial de la parte de número de 'hosts' de la dirección IP indica difusión en lugar de un 'host' específico. La capa IP receptora debe ser capaz de reconocer esta dirección de igual forma que la suya propia. Sin embargo, puede que todavía sea útil distinguir en niveles más altos entre las situaciones con difusión y sin difusión, especialmente en las pasarelas. Este constituye el caso más util de una difusión; permite a un 'host' descubrir pasarelas sin necesidad de tablas prefijadas, forma la base para los protocolos de resolución, y además es útil para acceder a utilidades como servidores de nombres, servidores de hora, etc., sin necesidad de direcciones prefijadas. - Difusión a todos los 'hosts' de una red física remota: Ocasionalmente resulta útil enviar una difusión a todos los 'hosts' de una red no local; por ejemplo, para averiguar la última versión de una base de datos de nombres de 'hosts', para arrancar un 'host' sobre una subred IP sin servidor de arranque, o para supervisar los servidores de la hora en la subred. Este caso es el mismo que el de las difusiones en la red local; el datagrama se encamina por los mecanismos normales hasta que alcance una pasarela conectada a la red física de destino, momento en el cuál se realiza la verdadera difusión. Esta clase de difusión tambien es conocida como "difusión dirigida", o, curiosamente, como envío de una "carta bomba" [1]. - Difusión a todos los 'hosts' de una red IP subdividida en subredes (difusiones en subredes múltiples): Un valor especial para la parte de número de subred de la dirección IP se utiliza para denotar a "todas las subredes". La difusiones a todos los 'hosts' de una red IP remota subdividida en subredes se realizan de la misma forma que las difusiones dirigidas a una subred única. Mogul [Pág. 4] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 - Difusión a la red Internet entera: Esto probablemente no sea útil y, casi con total seguridad, no deseable. Por razones de rendimiento o seguridad, una pasarela puede elegir no reenviar difusiones; de forma especial, puede ser buena idea el prohibir las difusiones hacia o desde un grupo autónomo de redes. 5. Métodos de difusión La capa receptora IP de un 'host' debe ser modificada para dar soporte a la difusión. En ausencia de difusiones, un 'host' determina si es el receptor de un datagrama comparando la dirección de destino con una de sus direcciones IP propias. Con una difusión, un 'host' debe comparar la dirección de destino no sólo con sus direcciones como 'host', sino también con las posibles direcciones de difusión para ese 'host'. El problema de enviar una difusión de la forma más adecuada ha sido muy estudiado [1, 3, 4, 13, 14]. Como se asume que el problema ya ha sido resuelto a nivel de la capa de enlace, un 'host' IP que desea enviar tanto una difusión local como una difusión dirigida necesita especificar únicamente la dirección de destino apropiada y enviar el datagrama en la forma usual. Los algoritmos sofisticados sólo son necesarios en las pasarelas. El problema de realizar una difusión a todos los 'hosts' de una red IP subdividida en subredes resulta aparentemente más difícil. Sin embargo, incluso en este caso, resulta que los algoritmos mejor conocidos no requieren ninguna complejidad adicional en los 'hosts' que no sean pasarelas. Un buen método de difusión debe satisfacer los siguientes criterios adicionales: - Sin modificación del formato de datagrama IP. - Eficiencia razonable en términos del número de copias generadas en exceso y el coste de los caminos elegidos. - Minimización de las modificaciones de las pasarelas, tanto en el espacio de código como de datos. - Alta probabilidad de entrega. El algoritmo que parece el mejor es el método de "Reenvío por el camino inverso" ('Reverse Path Forwarding', RPF) [4]. Aunque RPF no es óptimo en coste y fiabilidad, es un método bastante bueno, y es extremadamente sencillo de implementar, no necesitándose de ningún espacio adicional de datos en las pasarelas. 6. Las pasarelas y las difusiones. La mayor parte de la complejidad en dar soporte a la difusión reside en las pasarelas. Si una pasarela recibe una difusión dirigida a una red a la que no está conectada, simplemente la reenvía utilizando el Mogul [Pág. 5] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 mecanismo usual. En caso contrario, debe realizar un trabajo adicional. 6.1 Difusiones locales Cuando una pasarela recibe un datagrama de difusión local, hay varias cosas que puede realizar con él. La situación no admite ambigüedades, pero sin la precaución adecuada, es posible que se creen bucles infinitos. La acción que se debe tomar cuando se recibe un datagrama de difusión depende de varias cosas: la subred por la que se recibe el datagrama, la red de destino y las direcciones de la pasarela. - La regla principal para evitar bucles es "nunca difundas un datagrama en la red física por la que fue recibido". No es suficiente simplemente con evitar la repetición de datagramas provenientes de la propia pasarela ; esto todavía permitiría la existencia de bucles si hay varias pasarelas en la misma red física. - Si el datagrama se recibe en la red física a la que va dirigido, entonces no debe ser reenviado. Sin embargo, la pasarela debería considerarse ella misma como destino del datagrama (por ejemplo, podría tratarse de una actualización de la tabla de encaminamiento). - En otro caso, si el datagrama está dirigido a una red física a la que la pasarela está conectada, debe ser enviado como una difusión (en la capa de enlace de datos) de esa red. Nuevamente, la pasarela debería considerarse ella misma como destino del datagrama. - En cualquier otro caso, la pasarela debería seguir su procedimiento habitual de encaminamiento para escoger la pasarela siguiente y enviarle el datagrama. 6.2 Difusiones en subredes múltiples Cuando una pasarela recibe una difusión dirigida a todas las subredes de una red IP, debe utilizar el algoritmo de "Reenvío por el camino inverso" para decidir qué hacer. El método es simple: la pasarela debería reenviar copias del datagrama hacia todos sus enlaces conectados si y sólo si el datagrama llega por el enlace que es parte de la mejor ruta entre la pasarela y el origen del datagrama. En cualquier otro caso, el datagrama debería ser descartado. Este algoritmo puede mejorarse si alguna o todas las pasarelas intercambian información adicional entre ellas; esto puede realizarse de forma transparente desde el punto de vista del resto de 'hosts' e incluso del resto de las pasarelas. Véase [4,3] para Mogul [Pág. 6] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 más detalles. 6.3 Algoritmo de encaminamiento en pseudo-Algol Esto es la descripción en pseudo-Algol del algoritmo de encaminamiento que una pasarela debería utilizar. El algoritmo se muestra en la figura 1. Algunas definiciones empleadas: EncaminaEnlace('host') Una función que toma una dirección de 'host' como parámetro y que devuelve el enlace del primer salto en el camino de la pasarela al 'host'. EncaminarHost('host') Como la función anterior pero devolviendo la dirección del 'host' del primer salto ResolverDireccion('host') Devuelve la dirección física de un 'host' IP. EnlaceDeEntrada El enlace por el que llegó el paquete. CjtoEnlacesDeSalida El conjunto de enlaces a los que el paquete deb ería ser enviado. HostFisicoDeSalida La dirección física del 'host' a la que el paquete es enviado. Destino.host La parte de 'host' de la dirección de destino. Destino.subred La parte de subred de la dirección de destino. Destino.red_ip La parte de red IP de la dirección de destino. Mogul [Pág. 7] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 COMIENZO SI Destino.red_ip EN TodosLosEnlaces ENTONCES COMIENZO SI EstaSubdividaEnSubredes(Destino.red_ip) ENTONCES COMIENZO SI Destino.subred = SubredDeDifusion ENTONCES COMIENZO /* algoritmo de reenv. por el camino inverso */ SI EnlaceDeEntrada = EncaminarEnlace(origen) ENTONCES COMIENZO SI Destino.host = HostDeDifusion ENTONCES CjtoEnlacesDeSalida <- TodosLosEnlaces - EnlaceDeEntrada; HostDeSalida <- HostDeDifusion; Examinar el paquete para posible uso interno; FIN SINO /* duplicado de otra pasarela, descartar */ Descartar; FIN SINO SI Destino.subred = EnlaceDeEntrada.subred ENTONCES COMIENZO /* el reenvío causaría un bucle */ SI Destino.host = HostDeDifusion ENTONCES Examinar el paquete para posible uso interno; Descartar; FIN SINO COMIENZO /* reenviar a la subred (posibl. local) */ CjtoEnlacesDeSalida <- EncaminarEnlace(Destino); HostDeSalida <- EncaminarHost(Destino); FIN FIN SINO COMIENZO /* destinado a una de nuestras redes locales */ SI Destino.red_ip = EnlaceDeEntrada.red_ip ENTONCES COMIENZO /* el reenvío causaría un bucle */ SI Destino.host = HostDeDifusion ENTONCES Examinar el paquete para posible uso interno; Descartar; FIN SINO COMIENZO /* podría tratarse de una difusión */ CjtoEnlacesDeSalida <- EncaminarEnlace(Destino); HostDeSalida <- EncaminarHost(Destino); FIN FIN FIN SINO COMIENZO /* reenvío a una red IP no local */ CjtoEnlacesDeSalida <- EncaminarEnlace(Destino); HostDeSalida <- EncaminarHost(Destino); FIN HostFisicoDeSalida <- ResolverDireccion(HostDeSalida); FIN Fig. 1: Algoritmo en pseudo-Algol de encamin. de difusiones por pasarelas Mogul [Pág. 8] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 7. Direccionamiento de difusiones IP - Convenciones Para que las diferentes implementaciones de IP sean compatibles, debe existir una convención con un número especial para denotar a "todos los hosts" y a "todas las subredes". Como la capa de red local puede siempre asociar una dirección IP con una dirección de la capa de enlace de datos, la elección de un "número de host de difusión" de IP es bastante arbitraria. Por simplicidad, debería ser un número improbable de ser asignado a un 'host' real. El número cuyos bits son todos uno tiene esta propiedad; esta asignación fue propuesta por primera vez en [6]. En los pocos casos donde a un 'host' le había sido asignada una dirección con la parte del número de 'host' toda a unos, no parece oneroso el exigir que se vuelva a numerar. El número "todas las subredes" también consiste en todo unos; esto significa que un 'host' que quiera realizar una difusión a todos los 'hosts' de una red IP remota no necesita saber como la dirección de destino se ha dividido en campos de subred y de 'host' o incluso si se ha dividido en absoluto. Por ejemplo, 36.255.255.255 puede denotar todos los 'hosts' de una red física única, o todos los 'hosts' de una red IP subdivida empleando 1 octeto para el campo de subred y 2 octetos para el campo de 'host', o cualquier otra división posible. La dirección 255.255.255.255 denota una difusión a la red física local, que no debe ser reenviada. Esta dirección puede ser utilizada, por ejemplo, por 'hosts' que no conozcan su número de red y pregunten por él a algún servidor. Así, un 'host' en la red 36, por ejemplo, puede: - difundir a todos sus vecinos inmediatos utilizando 255.255.255.255 - difundir a todos los de la red 36 utilizando 36.255.255.255 sin saber si la red está subdividida; si no lo está, entonces ambas direcciones tienen el mismo efecto. Una aplicación robusta podría intentar la primera dirección, y si no recibe respuesta, entonces intentar la segunda más tarde. Véase [1] para una discusión de tales técnicas de "búsqueda en anillo en expansión". Si el uso de "todo unos" en un campo de una dirección IP significa "difusión", el uso de "todo ceros" podría interpretarse como dirección "sin especificar". Probablemente, no haya otra razón para que aparezcan tales direcciones más que la dirección de origen de un datagrama ICMP de "solicitud de información". Sin embargo, como convención notacional, se referirá a las redes (para diferenciarlas de los 'hosts') utilizando direcciones Mogul [Pág. 9] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 con campos de ceros. Por ejemplo, 36.0.0.0 significa "la red número 36", mientras que 36.255.255.255 significa "todos los hosts de la red número 36". 7.1. Servidores de ARP y difusiones El "protocolo de resolución de direcciones" (ARP, 'Address Resolution Protocol'), descrito en [11], puede, si no se implementa correctamente, causar problemas cuando se utilizan difusiones en una red donde no todos los 'hosts' comparten el conocimiento de qué es una dirección de difusión. Siempre existe la tentación de modificar el servidor de ARP de tal forma que proporcione la asociación entre una dirección de difusión IP y la dirección de difusión física. Hay que resistirse ante esta tentación. Un servidor de ARP no debería responder nunca a una solicitud cuyo objetivo sea una dirección de difusión. Tal solicitud puede provenir únicamente de un 'host' que no reconoce la dirección de difusión como tal y, por tanto, el hacerle caso llevaría casi irremediablemente a un bucle de reenvío. Si hay N de tales 'hosts' en la red física que no reconocen la dirección de difusión, entonces un datagrama enviado con un "tiempo de vida" igual a T podría, potencialmente, dar lugar a T**N redifusiones espurias. 8. Referencias [1] David Reeves Boggs. Internet Broadcasting. Ph.D. Th., Stanford University, Enero de 1982. [2] D.D. Clark, K.T. Pogran, and D.P. Reed. "An Introduction to Local Area Networks". Proc. IEEE 66, 11, pp1497-1516, 1978. [3] Yogan Kantilal Dalal. Broadcast Protocols in Packet Switched Com­ puter Networks. Ph.D. Th., Stanford University, Abril de 1977. [4] Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding of Broadcast Packets". Comm. ACM 21, 12, pp1040-1048, Diciembre de 1978. [5] The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications. Version 1.0, Digital Equipment Corporation, Intel, Xerox, Septiembre de 1980. [6] Robert Gurwitz and Robert Hinden. IP - Local Area Network Address­ ing Issues. IEN-212, Bolt Beranek and Newman, Septiembre de 1982. Mogul [Pág. 10] RFC 922 Difusión de datagramas de internet con subredes Octubre 1984 [7] R.M. Metcalfe and D.R. Boggs. "Ethernet: Distributed Packet Switch­ ing for Local Computer Networks". Comm. ACM 19, 7, pp395-404, Julio de 1976. También CSL-75-7, Xerox Palo Alto Research Center, reeditado en CSL-80-2. [8] Jeffrey Mogul. Internet Subnets. RFC-917, Stanford University, Octubre de 1984. [9] David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, Junio de 1981. [10] William W. Plummer. Internet Broadcast Protocols. IEN-10, Bolt Beranek and Newman, Marzo de 1977. [11] David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, Septiembre de 1982. [12] Jon Postel. Internet Protocol. RFC 791, ISI, Septiembre de 1981. (N.T. Versión en castellano por P.J. Ponce de León: "Protocolo Internet", Mayo de 1999) [13] David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, Junio de 1980. [14] David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, Junio de 1980. Nota del traductor Este documento y las traducciones al español mencionadas en las ref­ erencias pueden encontrarse en: http://lucas.hispalinux.es/htmls/estandares.html El proyecto de traducción de RFC al español tiene su web de desarrollo en: http://www.arrakis.es/~pjleon/rfc-es Mogul [Pág. 11]