Network Working Group J. Mogul (Stanford) Request for Comments: 950 J. Postel (ISI) Agosto 1985 Procedimiento Estándar para División en Subredes en Internet Status de este memorándum Este RFC especifica un protocolo para la comunidad ARPA-Internet. Si se implementa la división en subredes, se recomienda encarecidamente el cumplimiento de estos procedimientos. La distribución de este memorándum es ilimitada. Panorama general Este memorándum discute la utilidad de "subredes" en redes de Internet, que son subsecciones lógicamente visibles de una única red de Internet. Por razones administrativas o técnicas, muchas organizaciones han elegido dividir una red de Internet en varias subredes, en lugar de obtener un conjunto de números de red de Internet. Este memorándum proporciona procedimientos para el uso de subredes. Estos procedimientos son para máquinas (por ejemplo, estaciones de trabajo). Los procedimientos usados por las pasarelas de subred y entre ellas no están completamente descritos. En la RFC-940 [7] se proporcionan motivos importantes e información de base para un estándar de división en subredes. Agradecimientos Este memorándum está basado en la RFC-917 [1]. Mucha gente contribuyó al desarrollo de los conceptos aquí descritos. En concreto, J. Noel Chiappa, Chris Kent, y Tim Mann proporcionaron importantes sugerencias. Zaw-Sing Su, Mike Karels, y el 'Gateway Algorithms and Data Structures Task Force' (GADS) realizaron contribuciones adicionales para dar forma a este memorándum. 1. Motivación La visión original del universo Internet fue la de una jerarquía de dos niveles: en el nivel superior, Internet como un todo, y en el nivel inferior, redes individuales, cada una con su propio número de red. Internet no tiene una topología jerárquica, más bien la interpretación de las direcciones es jerárquica. En este modelo de dos niveles, cada máquina ve su red como una entidad única: esto es, la red puede ser tratada como una "caja negra" a la cual están conectadas un conjunto de máquinas. Mogul & Postel [Pág. 1] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Si bien esta visión se ha mostrado simple y potente, un número de organizaciones la han encontrado inadecuada, y han añadido un tercer nivel a la interpretación de las direcciones de Internet. En esta visión, una determinada red de Internet esta dividida en un conjunto de subredes. El modelo de tres niveles es útil en redes pertenecientes a organizaciones moderadamente grandes (por ejemplo, Universidades o compañías con más de un edificio), donde a menudo es necesario utilizar más de un cable de 'Red de Área Local' (LAN) (Local Area Network) para cubrir un "área local". Cada LAN puede entonces ser tratada como una subred. Hay varias razones por las que una organización podía usar más de un cable para cubrir un campus: - Tecnologías diferentes: Especialmente en entornos de investigación, puede haber en uso más de una clase de LAN; por ejemplo, una organización puede tener cierto equipamiento que soporte Ethernet, y otro que soporte una red en anillo. - Límites de las tecnologías: La mayoría de las tecnologías de LAN imponen límites, basados en parámetros eléctricos, en el número de máquinas conectadas, y en la longitud total del cable. Es fácil exceder estos límites, especialmente los relacionados con la longitud del cable. - Congestión de la red: Es posible que un pequeño subconjunto de máquinas en una LAN monopolicen la mayoría del ancho de banda. Una solución común a este problema es dividir las máquinas en grupos donde las comunicaciones internas sean elevadas, y luego poner estos grupos en cables separados. - Enlaces punto a punto: A veces una "área local", como por ejemplo el campus de una Universidad, está dividida en dos localizaciones demasiado distantes como para conectarlas usando la tecnología de LAN preferida. En este caso, enlaces punto a punto de alta velocidad podían conectar varias LAN. Una organización que se haya visto forzada a utilizar más de una LAN tiene tres opciones para asignar direcciones de Internet: 1. Obtener un número de red de Internet distinto para cada cable; no se usan subredes. 2. Usar un único número de red para toda la organización, pero asignar los números de máquina sin importar en qué LAN se encuentra la máquina ("subredes transparentes"). Mogul & Postel [Pág. 2] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 3. Usar un único número de red, y particionar el espacio de direcciones de las máquinas asignando números de subred a las LAN ("subredes explícitas"). Cada una de estas aproximaciones tiene sus desventajas. La primera, aunque no requiere ningún protocolo nuevo o modificado, resulta en una explosión en el tamaño de las tablas de encaminamiento de Internet. Se propaga por todas partes información acerca de los detalles internos de la conectividad local, aunque es de poca o nula utilidad fuera de la organización local. Sería bueno evitar este problema, puesto que algunas implementaciones actuales de las pasarelas no tienen mucho espacio para las tablas de encaminamiento. La segunda aproximación requiere algún convenio o protocolo que haga que el conjunto de LAN aparente ser una sola red de Internet. Por ejemplo, esto se puede hacer en las LAN donde cada dirección de Internet sea traducida a una dirección hardware usando un 'Protocolo de Resolución de Direcciones' (ARP) (Address Resolution Protocol), haciendo que los bridges situados entre las LAN intercepten las peticiones ARP para los objetivos no locales, ver RFC-925 [2]. Sin embargo, no es posible hacer esto para todas las tecnologías de LAN, especialmente aquéllas donde actualmente no se usan protocolos de ARP, o si la LAN no soporta difusión. Un problema más fundamental es que los bridges deben descubrir en qué LAN está una máquina, quizás usando un algoritmo de difusión. El coste de las difusiones crece al aumentar el numero de LAN: también, el tamaño de las caché de traducción necesarias en los bridges crece con el número total de máquinas en la red. La tercera aproximación consiste en soportar subredes de manera explícita. Esto tiene una desventaja, y es que supone una modificación del 'Internet Protocol' (IP), y por lo tanto requiere cambios en las implementaciones de IP actualmente en uso (si se van a usar estas implementaciones en una red con subredes). Sin embargo, estos cambios son relativamente menores, y una vez realizados, proporcionan una solución simple y eficiente al problema. También, esta aproximación evita cualquier cambio que pudiera ser incompatible con las máquinas existentes en redes sin subredes. Además, cuando se toman decisiones de diseño apropiadas, es posible usar las máquinas que creen estar en una red sin subredes en redes que sí contienen subredes, tal y como se explica en la RFC-917 [1]. Esto es útil cuando no es posible modificar algunas de las máquinas para que soporten subredes de manera explícita, o cuando se prefiere una transición gradual. Mogul & Postel [Pág. 3] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 2. Estándares para el direccionamiento de subredes Lo primero que describe esta sección es una propuesta para la interpretación de las direcciones de Internet, con el fin de soportar subredes. A continuación, discute los cambios en el software de las máquinas para soportar subredes. Finalmente, presenta un procedimiento para descubrir qué interpretación de las direcciones se usa en una red dada (es decir, qué máscara de dirección se usa). 2.1. Interpretación de las direcciones de Internet Suponga que se le ha asignado un número de red de Internet a una organización, que más tarde ha dividido esa red en un conjunto de subredes, y que desea asignar direcciones a las máquinas: ¿ cómo debería hacerse esto ?. Puesto que hay mínimas restricciones en la asignación de la parte de "dirección local" de las direcciones de Internet, han sido propuestas varias aproximaciones para la representación del número de subred: 1. Campo de longitud variable: se puede usar cualquier número de bits de la parte de la dirección local para el número de subred; el tamaño de este campo, aunque constante para una red dada, varía de una red a otra. Si la longitud del campo es cero, entonces no se están usando subredes. 2. Campo de longitud fija: se usa un número específico de bits (por ejemplo, ocho) para el número de subred, si es que se usan subredes. 3. Campo de longitud variable auto-codificada: de la misma forma en que la longitud (es decir, la clase) del número de red esta codificada en los bits altos, la longitud del campo de subred se codificará de manera parecida. 4. Campo de longitud fija auto-codificada: se usa un número de bits específico para el número de subred. 5. Bits enmascarados: se usa una máscara de bits ("máscara de red") para identificar qué bits del campo de dirección local indican el número de subred. ¿ Qué criterio se puede usar para elegir uno de estos cinco esquemas ?. Primero, ¿ podríamos usar un esquema de auto- codificación ?. Y, ¿ debería ser posible decir, con sólo examinar una dirección de Internet, si ésta se refiere a una red con subredes ?. Mogul & Postel [Pág. 4] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Una característica importante de la auto-codificación es que permite que el espacio de direccionamiento de una red sea dividido en subredes de diferentes tamaños, típicamente una subred con la mitad del espacio de direccionamiento y un conjunto de pequeñas subredes. Por ejemplo, considere una red de clase C que use un esquema de auto-codificación con un bit para indicar si se trata de la subred grande o no, y otros tres bits adicionales para identificar la subred pequeña. Si el primer bit es cero, entonces se trata de la subred grande, si el primer bit es uno entonces los siguiente bits (3 en este ejemplo) dan el número de subred. Existe una subred con 128 direcciones de máquina, y ocho subredes con 16 máquinas cada una. Para establecer un estándar de división en subredes, los parámetros y la interpretación del esquema de auto-codificación deben estar fijados y ser consistentes en todo Internet. Se podría asumir que todas las redes están divididas en subredes. Esto permitiría interpretar las direcciones sin necesidad de ninguna otra información. Es una ventaja significativa que dada una dirección de Internet no sea necesaria información adicional para que la implementación determine si dos direcciones se encuentran en la misma subred. Sin embargo, esto también puede verse como una desventaja: podría causar problemas en redes donde existen números de máquina que usan bits arbitrarios en la parte de la dirección local. En otras palabras, es útil ser capaz de controlar si una red está subdividida independientemente de la asignación de las direcciones de máquina. La alternativa es mantener separado de la dirección el hecho de que una red esté subdividida. Si de algún modo alguien encuentra que la red está subdividida, entonces se seguirán las reglas estándares para las direcciones de redes subdivididas mediante auto-codificación, de lo contrario se seguirán las reglas para las direcciones de redes no subdivididas. Si no se usa un esquema auto-codificado, no hay razón alguna para usar un esquema con campo de longitud fija: puesto que en cualquier caso tiene que haber algún "indicador" en cada red que indique si se están usando subredes, el coste adicional de usar un entero (anchura del campo de subred, o máscara de subred) en lugar de un booleano es despreciable. La ventaja de usar el esquema con máscara de subred es que permite que cada organización elija la Mogul & Postel [Pág. 5] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 mejor manera de asignar los relativamente pocos bits de la dirección local a los números de subred y de máquina. Por lo tanto, elegimos el esquema con máscara de dirección: es el esquema más flexible, y aún así no es más costoso de implementar que cualquiera de los otros. Por ejemplo, la dirección de Internet podría interpretarse como: donde el campo es el definido por IP [3], el campo ocupa, al menos, 1 bit, y la longitud del campo es constante para una red dada. No se requiere una estructura adicional para los campos y . Si la longitud del campo es cero, entonces la red no está subdividida (es decir, se usa la interpretación de [3]). Por ejemplo, en una red de clase B con un campo de subred de 6 bits, una dirección se dividiría de esta manera: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| RED | SUBRED | Número de Máquina | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Puesto que los bits que identifican la subred son especificados por una máscara de bits, no es necesario que se encuentren adyacentes a la dirección de red. Sin embargo, recomendamos que los bits de subred sean contiguos a la dirección de red y se sitúen en los bits más significativos de la dirección local. Direcciones Especiales: Del memorándum de Assigned Numbers 'Números Asignados' [9]: "En ciertos contextos, es útil tener direcciones fijas con significado funcional, más que como identificadores de máquinas específicas. Cuando se reclame esta utilización, la dirección cero será interpretada con el significado de "éste", como en "ésta red". La dirección con todo unos será interpretada con el significado de "todos", como en "todos las máquinas". Por ejemplo, la dirección 128.9.255.255 podía ser interpretada con el significado de todas las máquinas en la red 128.9. O la dirección 0.0.0.37 podía ser interpretada con el significado de la máquina 37 en esta red." Mogul & Postel [Pág. 6] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Es útil preservar y extender la interpretación de estas direcciones especiales en redes subdivididas. Esto significa que los valores de todo ceros y todo unos en el campo de subred no deberían ser asignados a subredes reales (físicas). En el ejemplo anterior, el campo de subred de 6 bits de longitud puede tomar cualquier valor excepto 0 y 63. Por favor, dese cuenta que no hay ningún efecto o nueva restricción en las direcciones de las máquinas en las redes no subdivididas. 2.2. Cambios en el software de las máquinas para soportar subredes. En la mayoría de las implementaciones de IP existe código en el módulo que maneja los datagramas salientes para decidir si un datagrama puede ser enviado directamente al destino en la red local, o si debe ser enviado a la pasarela. En general, el código es como éste: IF ip_net_number(dg.ip_dest) = ip_net_number(my_ip_addr) THEN send_dg_locally(dg, dg.ip_dest) ELSE send_dg_locally(dg, gateway_to(ip_net_number(dg.ip_dest))) (Si el código soporta redes múltiplemente conectadas, será más complicado, pero esto es irrelevante en la presente discusión.) Para soportar subredes, es necesario almacenar un número más de 32 bits, llamado my_ip_mask. Este número es una máscara de bits en la cual se encuentran a uno los bits correspondientes tanto al campo del número de red IP como al campo del número de subred. En este caso el código se convierte en: IF bitwise_and(dg.ip_dest, my_ip_mask) = bitwise_and(my_ip_addr, my_ip_mask) THEN send_dg_locally(dg, dg.ip_dest) ELSE send_dg_locally(dg, gateway_to(bitwise_and(dg.ip_dest, my_ip_mask))) Parte de la expresión en la sentencia condicional puede estar precalculada. Mogul & Postel [Pág. 7] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Puede ser o no necesario modificar la función "gateway_to", para que también tenga en cuenta los bits del campo de subred cuando se realicen comparaciones. Para soportar máquinas múltiplemente conectadas, se puede modificar el código para mantener los números "my_ip_addr" y "my_ip_mask" para cada interfaz; las expresiones en la sentencia condicional entonces deben ser evaluadas para cada interfaz. 2.3. Encontrando la Máscara de Red ¿ Cómo puede una máquina determinar la máscara de red usada en una subred a la que está conectada ?. El problema es similar a otros problemas de "arranque" para las máquinas de Internet: cómo determina una máquina su propia dirección, y cómo localiza la pasarela en su red local. En los tres casos, hay dos soluciones básicas: información "grabada a fuego", y protocolos basados en difusión. La información "grabada a fuego" es aquélla de la que una máquina dispone aislada de la red. Puede estar precompilada, o (preferiblemente) almacenada en un fichero de disco. Sin embargo, en los casos cada vez más habituales de estaciones de trabajo sin disco que arrancan sobre la LAN, ninguna de las soluciones "grabadas a fuego" es satisfactoria. En su lugar, y puesto que la mayoría de las tecnologías de LAN soportan difusión, un método mejor es que la máquina recién arrancada difunda una petición para obtener la información necesaria. Por ejemplo, con el propósito de determinar su dirección de Internet, una máquina puede usar el 'Protocolo de Resolución Inversa de Direcciones' (RARP) (Reverse Address Resolution Protocol) [4]. Sin embargo, puesto que una máquina recién arrancada habitualmente necesita reunir varios datos (por ejemplo, su dirección IP, la dirección hardware de una pasarela, la dirección IP de un servidor de nombres de dominio, la máscara de la dirección de subred), de ser posible sería mejor obtener toda esta información en una petición, más que hacer numerosas difusiones en la red. Los mecanismos diseñados para arrancar estaciones de trabajo sin disco también pueden cargar ficheros de configuración específicos para cada máquina, que contengan la información requerida (por ejemplo, vea RFC-951 [8]). Es posible, y deseable, obtener todos los datos necesarios para operar una máquina desde un servidor de arranque usando un sólo mensaje de difusión. Mogul & Postel [Pág. 8] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 El siguiente mecanismo se proporciona para el caso donde sea necesario que una máquina encuentre la máscara de red como una operación separada: Para proporcionar la información sobre la máscara de dirección, se extiende el protocolo ICMP [5] añadiéndole un nuevo par de tipos de mensaje ICMP, "Address Mask Request" y "Address Mask Reply", análogos a los mensajes ICMP "Information Request" e "Information Reply". Estos se encuentran descritos con detalle en el Apéndice I. El uso previsto para estos nuevos mensajes ICMP es que la máquina, durante el arranque, difunda un mensaje "Address Mask Request". Una pasarela (o una máquina actuando en lugar de una pasarela) que reciba este mensaje responde con un "Address Mask Reply". Si en la petición no se indica qué máquina la envió (es decir, la dirección IP origen es cero), la respuesta también será difundida. La máquina que hizo la petición oirá la respuesta, y a partir de ella determinará la máscara de la dirección. Puesto que en una red dada sólo hay un valor posible que pueda enviarse en un "Address Mask Reply", no es necesario que la máquina solicitante empareje las respuestas que oiga con la petición que envió; análogamente, no hay problemas si responde más de una pasarela. Asumimos que las máquinas no reinician de manera frecuente, por lo que la carga de difusiones en una red debido al uso de este protocolo debería ser pequeña. Si una máquina está conectada a más de una LAN, podría tener que encontrar la máscara de dirección para cada una de ellas. Un problema potencial es qué debería hacer una máquina si no puede encontrar la máscara de dirección, incluso tras un número razonable de intentos. Esta situación se puede interpretar de tres maneras: 1. La red local existe, y está (permanentemente) aislada de las demás redes. 2. No se usan subredes, y no hay máquina alguna que pueda proporcionar la máscara de dirección. 3. Todos las pasarelas de la red local se encuentran (temporalmente) caídas. La primera y segunda situaciones implican que la máscara de dirección es idéntica a la máscara del número de red de Internet. Mogul & Postel [Pág. 9] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 En la tercera situación, no hay manera de determinar qué valor es el adecuado; de este modo, la elección más segura es una máscara idéntica a la máscara del número de red de Internet. Aunque posteriormente podría demostrarse que esto era falso, no impedirá las transmisiones que de otra manera funcionarían. Es posible que una máquina se recupere de una elección errónea: cuando surge una pasarela, ésta debería difundir un "Address Mask Reply"; cuando una máquina recibe dicho mensaje, que no concuerda con su suposición, debería cambiar su máscara para estar de acuerdo con el valor recibido. Ninguna máquina o pasarela debería enviar un "Address Mask Reply" basado en un valor "supuesto". Finalmente, dese cuenta que no se requiere que una máquina utilice este protocolo ICMP para descubrir la máscara de dirección: es perfectamente razonable que una máquina con almacenamiento no volátil utilice la información almacenada (incluyendo un fichero de configuración del servidor de arranque). Mogul & Postel [Pág. 10] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Apéndice I. ICMP para Máscara de Dirección Address Mask Request o Address Mask Reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Código | Suma de Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificador | Número de Secuencia | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Máscara de Dirección | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campos IP: Direcciones La dirección del origen en un mensaje de petición de máscara de dirección será el destino del mensaje de respuesta de máscara de dirección. Para componer un mensaje de respuesta de máscara de dirección, la dirección origen de la petición se convierte en la dirección destino de la respuesta, la dirección origen de la respuesta se establece a la dirección de quien responde, el código de tipo cambiado a AM2, el valor de la máscara de dirección insertado en el campo Máscara de Dirección, y la suma de control será recalculada. Sin embargo, si la dirección origen en el mensaje de petición es cero, entonces la dirección destino para el mensaje de respuesta debería indicar una difusión. Campos ICMP Tipo AM1 para el mensaje de petición de máscara de dirección AM2 para el mensaje de respuesta de máscara de dirección Código 0 para el mensaje de petición de máscara de dirección 0 para el mensaje de respuesta de máscara de dirección Suma de Control La suma de control es el complemento a uno de 16 bits de la Mogul & Postel [Pág. 11] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 suma de los complementos a uno del mensaje ICMP, comenzando con en Tipo ICMP. Para calcular la suma de control, el campo Suma de Control debería ser cero. Esta suma de control puede ser remplazada en el futuro. Identificador Un identificador que ayude a asociar peticiones y respuestas, puede ser cero. Número de Secuencia Un número de secuencia que ayude a asociar peticiones y respuestas, puede ser cero. Máscara de Dirección Una máscara de 32 bits. Descripción Una pasarela que reciba una petición de máscara de dirección debería responder con el campo de máscara de dirección establecido a la máscara de 32 bits que identifica la red y la subred, para aquella subred por la cual recibió la petición. Si la máquina solicitante no conoce su propia dirección IP, puede dejar a cero el campo origen; en este caso la respuesta debería ser difundida. Sin embargo, de ser posible debería evitarse esta aproximación, puesto que incrementa la carga de difusiones superfluas en la red. Incluso cuando las respuestas sean difundidas, como sólo hay una posible máscara de dirección para una subred, no es necesario asociar las peticiones con las respuestas. Los campos "Identificador" y "Número de Secuencia" pueden ser ignorados. Se puede recibir un Tipo AM1 desde una pasarela o desde una máquina Se puede recibir un Tipo AM2 desde una pasarela, o desde una máquina actuando en lugar de una pasarela Mogul & Postel [Pág. 12] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Apéndice II. Ejemplos Estos ejemplos muestran cómo una máquina puede encontrar la máscara de dirección usando los mensajes ICMP "Address Mask Request" y "Address Mask Reply". Para los ejemplos siguientes, asuma que la dirección 255.255.255.255 denota "difusión sobre este medio físico" [6]. 1. Caso de una Red de Clase A Para este caso, asuma que la máquina solicitante se encuentra en una red clase A 36.0.0.0, tiene dirección 36.40.0.123, que hay una pasarela en 36.40.0.62, y que se usa un campo de subred de 8 bits de longitud, es decir, que la máscara de dirección es 255.255.0.0. El método más eficiente, el cual recomendamos, es que la máquina primero descubra su propia dirección (quizás, usando "RARP" [4]), y que entonces envíe la petición ICMP a 255.255.255.255: Dirección origen: 36.40.0.123 Dirección destino: 255.255.255.255 Protocolo: ICMP=1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 La pasarela puede en este caso responder directamente a la máquina solicitante. Dirección origen: 36.40.0.62 Dirección destino: 36.40.0.123 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.0.0 Suponga que 36.40.0.123 es una estación de trabajo sin disco, y que ni siquiera sabe su propio número de máquina. Puede enviar el siguiente datagrama: Dirección origen: 0.0.0.0 Dirección destino: 255.255.255.255 Protocolo: ICMP = 1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 36.40.0.62 oirá el datagrama, y respondería con este datagrama: Mogul & Postel [Pág. 13] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Dirección origen: 36.40.0.62 Dirección destino: 255.255.255.255 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.0.0 Dese cuenta que la pasarela usa la difusión más restringida posible para responder. Aún así, el abuso de difusiones supone una carga innecesaria para todas las máquinas de la subred, y por lo tanto el uso de la dirección origen "anónima" (0.0.0.0) debe reducirse al mínimo. Si la difusión no está permitida, asumimos que las máquinas disponen de información grabada acerca de las pasarelas vecinas; de este modo, 36.40.0.123 podía enviar este datagrama: Dirección origen: 36.40.0.123 Dirección destino: 36.40.0.62 Protocolo: ICMP = 1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 36.40.0.62 debería responder exactamente como en el caso anterior. Dirección origen: 36.40.0.62 Dirección destino: 36.40.0.123 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.0.0 2. Caso de una Red de Clase B Para este caso, asuma que la máquina solicitante se encuentra en una red de clase B 128.99.0.0, tiene dirección 128.99.4.123, que hay una pasarela en 128.99.4.62, y que se usa un campo de subred de 6 bits de longitud, es decir, que la máscara de dirección es 255.255.252.0. La máquina envía la petición ICMP a 255.255.255.255: Mogul & Postel [Pág. 14] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Dirección origen: 128.99.4.123 Dirección destino: 255.255.255.255 Protocolo: ICMP = 1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 La pasarela puede responder directamente a la máquina solicitante. Dirección origen: 128.99.4.62 Dirección destino: 128.99.4.123 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.252.0 En el caso de una estación de trabajo sin disco la máquina envía: Dirección origen: 0.0.0.0 Dirección destino: 255.255.255.255 Protocolo: ICMP = 1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 128.99.4.62 oirá el datagrama, y debería responder con este datagrama: Dirección origen: 128.99.4.62 Dirección destino: 255.255.255.255 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.252.0 Si la difusión no está permitida, 128.99.4.123 envía: Dirección origen: 128.99.4.123 Dirección destino: 128.99.4.62 Protocolo: ICMP = 1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 128.99.4.62 debería responder exactamente como en el caso anterior. Mogul & Postel [Pág. 15] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Dirección origen: 128.99.4.62 Dirección destino: 128.99.4.123 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.252.0 3. Caso de una Red de Clase C (con bits de subred no contiguos) Para este caso, asuma que la máquina solicitante se encuentra en una red de clase C 192.1.127.0, tiene dirección 192.1.127.19, que hay una pasarela en 192.1.127.50, y que se usa un campo de subred de 3 bits (01011000), es decir, que la máscara de dirección es 255.255.255.88. La máquina envía la petición ICMP a 255.255.255.255: Dirección origen: 192.1.127.19 Dirección destino: 255.255.255.255 Protocolo: ICMP = 1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 La pasarela puede en este caso responder directamente a la máquina solicitante. Dirección origen: 192.1.127.50 Dirección destino: 192.1.127.19 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.255.88 En el caso de una estación de trabajo sin disco la máquina envía: Dirección origen: 0.0.0.0 Dirección destino: 255.255.255.255 Protocolo: ICMP = 1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 192.1.127.50 oirá el datagrama, y debería responder con este datagrama: Mogul & Postel [Pág. 16] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Dirección origen: 192.1.127.50 Dirección destino: 255.255.255.255 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.255.88 Si la difusión no está permitida, 192.1.127.19 envía: Dirección origen: 192.1.127.19 Dirección destino: 192.1.127.50 Protocolo: ICMP = 1 Tipo: Address Mask Request = AM1 Código: 0 Máscara: 0 192.1.127.50 debería responder exactamente como en el caso anterior. Dirección origen: 192.1.127.50 Dirección destino: 192.1.127.19 Protocolo: ICMP = 1 Tipo: Address Mask Reply = AM2 Código: 0 Máscara: 255.255.255.88 Mogul & Postel [Pág. 17] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Apéndice III. Glosario Bridge Un nodo conectado a dos o más redes, administrativamente indistinguibles, pero físicamente distintas, que reenvía automáticamente datagramas cuando es necesario, pero cuya existencia no es conocida por las demás máquinas. También se le conoce como "repetidor software". Gateway (Pasarela) Un nodo conectado a dos o más redes y/o subredes administrativamente distintas, hacia el cual las máquinas envían datagramas para ser reenviados. Host Field (Campo de Máquina) El campo de bits en una dirección de Internet que se utiliza pata denotar a una máquina específica. Internet El conjunto de redes conectadas que usan el protocolo IP. Local Address (Dirección Local) El campo restante de la dirección de Internet (como se define en [3]). Network (Red) Una sola red de Internet (que puede o no estar dividida en subredes). Network Number (Número de Red) El campo de red de la dirección de Internet. Subnet (Subred) Una o más redes físicas que forman un subconjunto de una red de Internet. Una subred se identifica explícitamente en la dirección de Internet. Mogul & Postel [Pág. 18] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Subnet Field (Campo de Subred) El campo de bits en una dirección de Internet que denota el número de subred. Los bits que forman este campo no tienen porqué estar contiguos en la dirección. Subnet Number (Número de Subred) Un número que identifica a una subred dentro de una red. Apéndice IV. Números Asignados Se han hecho las siguientes asignaciones para los parámetros de los protocolos usados para soportar subredes. Las únicas asignaciones necesarias son para el Internet Control Message Protocol (ICMP) [5]. Tipos de Mensaje ICMP AM1 = 17 AM2 = 18 Mogul & Postel [Pág. 19] RFC 950 Procedimiento para Subredes en Internet Agosto 1985 Referencias [1] Mogul, J., "Internet Subnets", RFC-917, Universidad de Stanford, Octubre 1984. [2] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC/Infor­ mation Sciences Institute, Octubre 1984. [3] Postel, J., "Internet Protocol", RFC-791, USC/Information Sci­ ences Institute, Septiembre 1981. [4] Finlayson, R., T. Mann, J. Mogul, M. Theimer, "A Reverse Address Resolution Protocol", RFC-903, Universidad de Stanford, Junio 1984. [5] Postel, J., "Internet Control Message Protocol", RFC-792, USC/Information Sciences Institute, Septiembre 1981. [6] Mogul, J., "Broadcasting Internet Datagrams", RFC-919, Universi­ dad de Stanford, Octubre 1984. [7] GADS, "Towards an Internet Standard Scheme for Subnetting", RFC-940, Network Information Center, SRI International, Abril 1985. [8] Croft, B., and J. Gilmore, "BOOTP -- UDP Bootstrap Protocol", RFC-951, Universidad de Stanford, Agosto 1985. [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-943, USC/Information Sciences Institute, Abril 1985. Traducción al castellano: José Luis Domingo López C/ Cruz del Sur 22 28007 Madrid - España EMail: jdomingo@internautas.org Mogul & Postel [Pág. 20]