Network Working Group Jeffrey Mogul Request for Comments: 919 Computer Science Department Stanford University Octubre de 1984 DIFUSION DE DATAGRAMAS DE INTERNET (Traducción al castellano: Enero 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 [13], 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 [11]). 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 [10], redes de tipo "token ring" [2], etc. Mogul [Pág. 1] RFC 919 Difusión de Datagramas de Internet Octubre 1984 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 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. Nota: algunas organizaciones han dividido sus redes IP en subredes, caso para el cuál se ha propuesto un estándar [8]. Este RFC no cubre las numerosas complicaciones causadas por las interacciones entre las subredes y la difusión; ver [9] para una discusión completa. 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. Mogul [Pág. 2] RFC 919 Difusión de Datagramas de Internet Octubre 1984 Red IP Una red o una colección de varias redes físicas que tienen un número de red IP específico. 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 las difusiones cuando lo que se desea realmente son multienvíos; los 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, ver [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 IP 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 Mogul [Pág. 3] RFC 919 Difusión de Datagramas de Internet Octubre 1984 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 local IP: 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 util 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 IP 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 red IP sin servidor de arranque, o para supervisar los servidores de la hora en la red IP. 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 IP de destino, punto 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 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 la 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'. Mogul [Pág. 4] RFC 919 Difusión de Datagramas de Internet Octubre 1984 El problema de cómo enviar una difusión de la forma más adecuada ha sido muy estudiado [1, 3, 4, 14, 15]. 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. 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 mecanismo usual. En caso contrario, debe realizar un trabajo adicional. 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 recibió, 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. Mogul [Pág. 5] RFC 919 Difusión de Datagramas de Internet Octubre 1984 7. Direccionamiento de difusiones IP - Estándares propuestos Para que las diferentes implementaciones de IP sean compatibles, debe existir un número especial para denotar a "todos los hosts". 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" 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. 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 (Nótese que a menos que la red haya sido subdividada en subredes, estos dos métodos tienen efectos idénticos). 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 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 [12], 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 Mogul [Pág. 6] RFC 919 Difusión de Datagramas de Internet Octubre 1984 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. [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. Mogul [Pág. 7] RFC 919 Difusión de Datagramas de Internet Octubre 1984 [8] Jeffrey Mogul. Internet Subnets. RFC-917, Stanford University, Octubre de 1984. [9] Jeffrey Mogul. Broadcasting Internet Packets in the Presence of Subnets. RFC-922, Stanford University, Octubre de 1984. [10] David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, Junio de 1981. [11] William W. Plummer. Internet Broadcast Protocols. IEN-10, Bolt Beranek and Newman, Marzo de 1977. [12] David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, Septiembre de 1982. [13] 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) [14] David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, Junio de 1980. [15] 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. 8]