Network Working Group P. Tsuchiya Request for Comments: 1219 Bellcore April 1991 Acerca de la asignación de Direcciones en sub-redes (Traducción al castellano: Noviembre 1999) (Por: Juan Ignacio Rodriguez de León ) Categoría de este Memorandum Este documento sugiere un nuevo procedimiento para la asignación de números IP dentro de subredes. Aplicar esta técnica dentro de una red es un asunto puramente local, dado que no tendrá ningún efecto sobre otras redes. Por lo tanto, utilizar o no este procedimiento es totalmente opcional. Este memorandum proporciona información para la comunidad de usuarios de Internet. No especifica un estándar Internet. No existe ninguna limitación para La distribución de este documento. Introducción El documentos RFC-950 especifica un procedimiento para hacer una sub-red (subnetting) a partir de una dirección IP, utilizando una máscara de bits. Aunque esta especificación permite que los "unos" dentro de la mascara no sean contiguos, se recomienda: 1) que sean contiguos y 2) que ocupen los bits más significativos de la parte "host" de la dirección internet. RFC-950 no especifica si diferentes subredes dentro de la misma red pueden o no tener diferentes máscaras. Esta ambigüedad ha resultado desafortunada, ya que ha conducido a un desarrollo de protocolos de rutado que no soportan determinadas máscaras, por ejemplo RIP [6]. El RFC Requisitos de enrutamiento (Gateway Requirements) [7] estableció la posibilidad de permitir esta característica, por lo que se espera de los protocolos más recientes que soporten esta característica; OSPF [3] es un ejemplo. El administrador de la red debe determinar, por supuesto, la máscara de cada subred. Esto implica realizar una estimación del número máximo de nodos que tendrá cada subred. dado que en redes relativamente grandes es prácticamente imposible predecir como crecerá cada subred, a menudo se tomas medidas ineficaces, que producen unas redes infrautilizadas y otras sobrecargadas, cuyas máquinas probablemente deben ser renumeradas a causa de esta capacidad excedida. Este documento especifica un procedimiento para asignar direcciones a las subredes que eliminan la necesidad de estimar el tamaño de las subredes. Esencialmente, el método consiste en asignar los bits de la máscara que pertenecen al "host" (los ceros) desde el bit menos significativo a los más significativos, mientras que los bits de la mascara que pertenecen a la subred se asignan a la inversa, desde el bit más significativos a los menos. A medida que aumenta el número de subredes, se asigna mas bits a la máscara de subred. Aunque este proceso implica a veces modifica las máscaras de red, nunca es necesario cambiar las direcciones de los nodos. Esta técnica no es nueva, pero no es muy conocida, y aun menos veces utilizada. Con el desarrollo de nuevos métodos de rutado, como OSPF, es posible sacar el máximo provecho de ella. El propósito de este documento es, por lo tanto, difundir el conocimiento de esta técnica, así com especificarla claramente. Esta especificación no requiere ningún cambio en los actuales estándares de Internet. Si requiere, sin embargo, que los protocolos de rutado intra-dominios sean capaces de manejar diferentes máscaras de subred. Agradecimientos El autor quiere agradeces a Phil Karn, Charles Lynn, Jeff Mogul y Charles Wolverton por su útiles sugerencias. Un agradecimiento especial para Joel Halpern por su laboriosa comprobación de los detalles de la especificación y de los ejemplos. 1. Motivación La Norma de subredes, RFC-950. especifica que la parte del nodo de la dirección Internet (Formalmente limitada a dos niveles) puede subdividirse en dos campos, subred y nodo. De esta manera se proporciona a la dirección Internet un tercer nivel de jerarquía, lo que facilita una reducción en la sobrecarga de routers y cortafuegos. También incrementa el nivel de ineficiencia en la asignación de direcciones. Esta ineficacia proviene de que el administrador normalmente sobredimensiona el tamaño (número de nodos) de las subredes, para prevenir futuras modificaciones en la estructura de las subredes. También puede ocurrir que el protocolo de enrutado utilizado no sea capaz de manejar subredes de tamaño diferente, por lo que el administrador debe asignar a cada red un tamaño equivalente al de la subred más grande (Este RFC no ofrece ninguna ayuda en esta último caso, ya que la técnica aquí explicada requiere subredes de diferente tamaño). La carga de trabajo asociada con el cambio de la estructura de subredes de una red puede llegar ser considerable. Como ejemplo, considérese el siguiente caso. Una red mantiene tres subredes, A, B y C. Asumiendo que el byte menos significativo es la parte del nodo, mientras que el siguiente byte es la sección de subred (Es decir, la máscara es 255.255.255.0). Consideremos, así mismo, que la subred A es la 1.0, la B es la 2.0 y C es la 3.0. Supongamos ahora que la red B crece mas allá de su asignación inicial de 254 nodos. Lo ideal sería poder cambiar la máscara de la subred B sin tener que hacer ningún cambio en las direcciones de las máquinas en dicha red. Sin embargo, los subredes numéricamente superior e inferior ya están ocupadas por A y C (Si la dirección 3.0 no estuviera ocupada por A, se podría cambiar la máscara de B de 255.0 (FF00) a 254.0 (FE00). En este caso, todas las direcciones actuales de B seguirían encajando en la nueva subred. Aun más, si fuera posible usar máscaras no contiguas, B podría seleccionar otros bits de la máscara que podría cambiar a 0. No obstante, las máscaras no contiguas no son deseables, ya que imponen ciertas restricciones en determinados algoritmos de búsquedas. el RFC-950 concretamente desaconseja su uso). Por lo tanto, las opciones disponibles por el administrador son 1) crear dos subredes a partir de una ya existente, o 2) renumerar la subred de forma que se utilize una máscara de subred menor (Es decir, con menos unos). La primera opción se puede realizar físicamente o lógicamente. Físicamente, la creación de las dos subredes implica la partición de la subred inicial en dos, e insertar entre estos dos nuevos segmentos un mecanismo de rutado. Por razones obvias, este método dista mucho de ser el ideal. Lógicamente, se pueden formar las dos subredes simplemente asignado otro direccion de red (digamos la 4.0) a la subred inicial, y empezar a asignar nuevas direcciones de máquina en este espacio. El resultado de esta partición lógica es que los nodos que estén en diferentes subredes no se reconocerán como pertenecientes al mismo segmento, de forma que enviarán los paquetes al enrutador por defecto, en vez de enviarlos directamente al destino. En realidad, esta solución no es tan mala como podría parecer, ya que si el enrutador es capaz de reconocer múltiples direcciones de subred dentro de una subred, puede simplemente enviarle al nodo que envió el mensaje una Redirección ICMP [4], de forma que los paquetes siguientes irán directamente al destino [1] (Esta posibilidad puede no funcionar correctamente para todos los nodos). Si ninguna de las dos opciones anteriores son aceptables o posibles, el administrador deberá asignar una nueva dirección de subred a B, lo que implica cambiar las direcciones de todas las máquinas conectadas a B, modificar las entradas en el sistema de nombres de dominio (DNS), y modificar cualquier fichero de configuración en cualquier máquina que contenga direcciones IP para máquinas en la red B. 2. Una técnica para asignar direcciones de subred más flexible y eficiente. Con vistas a explicar mejor esta nueva técnica, debemos estudiar cuidadosamente los problemas de lo visto hasta ahora. En la actualidad, la mayoría de las subredes se asigna dividiendo la sección destinada a la máquina de la direccion IP en dos campos, la subred y la máquina. Los bits de la máscara son unos para indicar el campo de subred y ceros para indicar el campo de máquina (En todas nuestras direcciones, se considerará el bit menos significativo (LSB) el de la derecha, y el mas significativo (MSB) el de la izquierda). MSB LSB -------------------------------------- | Campo subred | Campo Máquina | -------------------------------------- El campo de subred puede ser de diferente longitud según el tamaño de la misma. Por ejemplo, supongamos que tenemos una red compuesta de dos grandes subredes (Por grande se debe entender con un gran número de máquinas conectadas) y varias otras redes más pequeñas. El administrador podría asignar dos tipos de direcciones: -------------------------------------- | subred | máquina | Subred grande -------------------------------------- -------------------------------------- | subred | máquina | subred pequeña -------------------------------------- En este caso, la totalidad del rango de direcciones no se podría asignar a las redes pequeñas, ya que los bits en la subred pequeña que correspondan con los de la subred grande no pueden utilizarse en esta. Supongamos, por ejemplo, que la máscara de la subred grande tiene un ancho de 4 bits, mientras que las redes pequeñas tienen un ancho de 8 bits. Si la subred grande tiene los valore 0001 y 0010, las direcciones en el rango 0001000 a 0010111 no se pueden asignar a las subredes pequeñas, ya que de lo contrario habría direcciones que pertenecerían a ambas subredes. Normalmente, el administrador de la red asignará valores a las dos subredes en el orden numérico habitual. Por ejemplo, dada una determinada dirección de subred, las máquinas se numerarán 1, 2, 3, etc. Dentro de una red, las subredes se numeraran de igual manera, 1, 2, 3 etc. Como resultado de esto, un cierto número de bits en el lado derecho del campo subred y del campo nodo consistirán en bits que cambiaran sus valores según la numeración de las máquinas, mientras que ciertos bits situados a la izquierda del campo subred y nodo serán siempre ceros. Los bits "Todo ceros" representan espacio para crecer, mientras que los bits "unos y ceros" representan espacio ya consumido. -------------------------------------- | campo subred | campo nodo | |-----+-----------+-------+------------| | | | | | | 0 | 1 ó 0 | 0 | 1 ó 0 | /\ /\ || || las subredes Los nodos pueden aumentar aquí pueden aumentar aquí Ahora, supongamos que el número de nodos en una determinada subred crece hasta el máximo permitido, pero que todavía hay espacio en el campo de la subred para asignar más direcciones. En este caso, tendríamos lo siguiente: -------------------------------------- | campo subred | campo host | |-----+-----------+--------------------| | | | | | 0 | 1 ó 0 | 1 ó 0 | Aunque el campo host ya no puede crecer más, todavía hay espacio disponible en la dirección para crecer. El problema es que, dada la situación donde se ha ubicado el area de crecimiento, este espacio ha quedado reservado solamente para las subredes. Lo que podríamos haber hecho es asignar los números de las subredes de forma que los unos empezaran desde la izquierda del campo subred hacia la derecha. En esa caso, tendríamos lo siguiente: -------------------------------------- | campo subred | campo host | |-----------+-------------+------------| | | | | | 1 ó 0 | 0 | 1 ó 0 | /\ || Tanto las subredes como los nodos pueden crecer aquí. Ahora, tanto los nodos como las subredes disponen de más espacio para crecer, aunque los bits disponibles para ello son los mismos. Dado que muy raramente se puede determinar a priori con cuantos nodos acabará una subred, o cuantas subredes distintas harán falta, este sistema permite la máxima flexibilidad en el crecimiento. En realidad, el esquema anterior es engañoso. El límite entre los campos de subred y nodo se muestran en la mitad del área de crecimiento. Sin embargo, el límite puede establecerse en cualquier sitio dentro del área de crecimiento. Nótese que es la propia máscara la que determina donde está la frontera. Los unos de la máscara indican el campo de subred, mientras que los ceros indican el campo de nodo. Veremos más adelante que, de hecho, el límite debe establecerse en algún sitio cercano a la mitad. En esa situación se minimiza el número de veces que la máscara debe ser cambiada en los nodos. 2.1 Especificaciones de la nueva técnica Una vez visto las explicaciones preliminares, podemos especificar el procedimiento para la asignación de las direcciones de las subredes. Para ello, haremos uso de las siguientes definiciones: Bits asignados al Nodo (h-bits): Son los bits, contiguos desde la derecha, que pueden contener, para una subred determinada, tanto unos como ceros. Subredes diferentes pueden tener diferentes h-bits Bits asignados a la Subred (s-bits): Son los bits, contiguos desde la izquierda, que 1) no son h-bits Y 2) son necesarios para poder distinguir una subred de otra, Y 3) incluyen todos los bits situados hacia la izquierda a partir del que esté más a la derecha (inclusive). Nótese que diferentes subredes pueden tener diferentes s-bits. Bits de crecimiento (g-bits): Son los que llamábamos "todo ceros", situados entre los h-bits y los s-bits. Máscara-S (s-mask): Dada una subred, es aquella máscara donde todos los s- bits son uno, y todos los g-bits y los h-bits son cero. Máscara-G (g-mask): Dada una subred, es la máscara donde todos los s-bits y los g-bits son cero, y todos los h-bits están a uno. Campo de subred (Subnet Field): Son los bits que están a uno en la máscara de subred (Tal y como se definen en el RFC-950). Estos bits están a la izquierda, Los campos de subred deben incluir, como mínimo, todos los s-bits, y pueden incluir opcionalmente alguno o todos los g-bits. Campo de nodo (Host Field): Son los bits que están a cero en la mascara de subred. Estos bits están a la derecha. El Campo de nodo debe incluir, como mínimo, todos las h-bits, y puede incluir opcionalmente alguno o todos los g-bits. Cuenta Reflejada: En la cuenta normal, en binario, los bits a uno empiezan a la derecha y van progresando hacia la izquierda. Así es como se asignan las direcciones de los nodos. Sin embargo, para asignar direcciones a las subredes, queremos exactamente lo contrario, que los bits empiecen a asignarse por la izquierda y vayan progresando hacia la derecha. Este procedimiento resulta ser el reflejo especular de una cuenta normal, donde el bit más significativo es intercambiado con el menos significativo, el segundo bit más significativo se intercambia con el segundo menos significativo, y así consecutivamente, De esta forma, una cuenta es: 0 (reservado para indicar "Este nodo") 01 10 011 100 101 : : 11...1110 11...1111 (reservado para indicar "Todos los nodos") y continuaría así. La cuenta reflejada sería: 0 (reservado para indicar "Esta subred") 10 01 110 001 101 : : 011...11 111...11 (reservado para indicar "Todas las subredes") Si la cuenta reflejada es, digamos, 001, el siguiente valor reflejado sería el 101, mientras que el anterior sería el 11 Ahora ya estamos en condiciones de especificar el algoritmo. Suponemos que contamos con las siguientes funciones: Initialize(), AddSubnet(), RemoveSubnet(subred#), AddHost(subred#), y RemoveHost(subred#,host#). Nótese que el algoritmo se describe como si una máquina de estados estuviera ejecutándolo. En realidad, debería haber una Autoridad de Direcciones raíz (ADRaiz) que asigne las direcciones de subred (Initialize, AddSubnet, y RemoveSubnet), y una Autoridad de Direcciones para cada subred (ADSubred), que asigne las direcciones de los nodos dentro de la subred (AddHost y RemoveHost). Aunque por lo general las Autoridades pueden actuar independientemente, hay dos casos en los que se requiere una coordinación entre la Autoridad raíz y una Autoridad de Subred. Estos casos son donde o bien el ADRaiz o el ADSubred "agarran" el último bit de crecimiento (En el primer caso porque se ha añadido una nueva subred, en el segundo porque se ha añadido otro nodo). Dado que es imposible que ambas autoridades atrapen ese último bit a la vez, solo uno de los dos podrá quedarse con el. Finalmente, nótese que se usarán las siguientes convenciones, propias del lenguaje de programación C. & función AND a nivel de bits == es igual a != es diferente de x-mask(X) la máscara de X, (donde X es s o g) Initialize(): Asignar el primer valor de las subredes a cero (El valor reservado para indicar "Esta subred"). Este número nunca se asigna a ninguna subred. AddSubnet(): 1. Encontrar el menor número distinto de cero (en cuenta reflejada) S, que no está asignado a ninguna subred, y tal que (S & g-mask(Y)) != (Y & g-mask(Y)) para todas las direcciones de subred existentes Y (Y != S). 2. Si todos los bits en S situados a la izquierda del bit más a la derecha son unos, etiquetar todos los bits mas un bit adicional a la derecha como s-bits, en caso contrario, etiquetar como s-bits todos los bits desde la izquierda hasta el bit más a la derecha. Esto previene que utilicemos el valor especial "todo unos" (utilizado para enviar mensajes a todos los nodos de la red) como dirección de subred (Dado que no hay ningún nodo asignado a esta red, el bit que este más a la derecha y que valga uno es un bit de subred). 3. Etiquetar los bits restantes de la direccion como g-bits (Por dirección se debe entender la parte de la dirección IP excluyendo la parte de red). 4. Ajustar la máscara de subred para que incluya, al menos, todos los s-bits, y opcionalmente algunos g-bits. La máscara de subred debe ser contigua (En la sección 2.2 se explicarán los pros y los contras de la elección de la máscara). 5. Para todas las direcciones Y de subred existentes (Y != S): 5.1: Si (S & s-mask(Y)) == (Y & s-mask(Y)), entonces: 511. Cambiar el g-bit más a la izquierda de Y a s-bit. Si la administración raíz (ADRaiz) es distinta de la administración de la subred Y (ADSubred), esta deberá ser informada del cambio. Si el bit cambiado es el último bit de crecimiento, el cambio debe ser coordinado por la autoridad raíz. 512. Expandir la máscara de subred para todos los hosts en Y si fuera necesario (Es decir, si la máscara de subred no incluye todos los s-bits) RemoveSubnet(S): 1. Considerar B como la posición del s-bit más a la derecha en S. 2. Borrar S 3. Para todas las subredes Y existentes: 31 Si el bit en la posición B no es un s-bit, o si el bit en la posición B es un uno, o si el bit en la posición B es cero y todos los bits a la izquierda de B son unos, entonces, no hay que hacer nada (ignorar los pasos 32 y 33). 32. Cambiar el s-bit que está en la posición B a g-bit. 33. Si para cualquier subred existente X, donde (X & s-mask(Y)) == (Y & s-mask(Y)), cambiar el g-bit en la posición B de nuevo a s-bit para Y, En caso contrario, informar a la Autoridad de direcciones de Y del cambio en el estado del bit. AddHost(S): 1. Crear una dirección A consistente en la dirección de la subred S concatenada con ceros. 2. Asignar a A los mismos h-bits, g-bits y s-bits que las demás direcciones de nodos. 3. Encontrar la dirección de nodo más pequeña, que sea distinta de cero (usando cuenta normal), y que esté sin asignar. 4. Si todos los bits a contar desde el bit más a la izquierda que valga uno hasta la posición 0 son unos, ejecutar los pasos 5 y 6 usando la posición B como un bit a la izquierda del bit con valor uno más hacia la izquierda. Esto impide utilizar el valor especial "Todo unos" (Que se utiliza para direccionas un mensaje a todos los nodos de la red) a un nodo de la red. 5. Si el bit en la posición B es un s-bit, entonces no se puede añadir el nodo. Ignorar los pasos siguientes. 6. Si el bit en la posición B es un g-bit: 61. Cambiar el g-bit a h-bit para todos los nodos de S. Obsérvese que si fuera el último g-bit, este cambio debería ser coordinado con la autoridad que asigne las direcciones dentro la subred (ver sección 2.2) 62. Modificar la máscara de subred en todos los nodos en que fuera necesario 7. Crear una nueva dirección A compuesta de S concatenado con H 8. Asignar la direccion A al host. RemoveHost(S,H): 1. Eliminar H. 2. Si para todas las restantes direcciones de host en S, el valor del h-bit situado más a la izquierda es cero, y hay un cero en al menos una de las posiciones a la derecha del h-bit más a la izquierda, entonces cambiar el h-bit más a la izquierda en un g-bit, para todos los nodos. Merece la pena hacer notar que esta técnica en un subconjunto del esquema de direccionamiento kampai [5], más general (nivel n), reducido al nivel 2. La diferencia principal es que el método general para n niveles conduce a máscaras no contiguas, mientras que con el nivel 2 no. En la descripción del método kampei [5],los g-bits se denominan a-bits, los h-bits se llaman g- bits, y los s- bits se llaman i-bits. 2.2 Un ejemplo Para este ejemplo, asumiremos que disponemos de una dirección de red clase C, así que solamente necesitaremos trabajar con 8 bits. Empezaremos con 3 subredes, A, B y C. Nuestra nomenclatura es h para los h-bits y g para los g- bits. Obsérvese que los h-bits pueden ser unos o ceros, pero los g-bits son siempre cero. Los bits restantes son s-bits, pero se muestran como unos o ceros en concordancia con la asignación de subred. los espacios son solo para que los ejemplos sean más fáciles de leer. Finalmente, numeramos nuestros bits de 0 a 7 desde la derecha hacia la izquierda, tal y como se muestra a continuación: Subred Dirección Máscara A 10gg ghhh 1111 0000 B 01gg ghhh 1111 0000 C 110g ghhh 1111 0000 bit 7 bit 0 Se puede comprobar que cada subred puede albergar hasta 6 hosts (a causa de los tres h-bits). Obsérvese que hemos elegido las máscaras de forma que haya espacio de crecimiento tanto para el campo nodo como para el campo subred, sin necesidad de cambiar la máscara de subred. Sin embargo, hemos permitido un mayor crecimiento en las subredes que en los nodos, porque añadir nuevas subredes puede ocasionar cambios de máscara en las subredes existentes, mientras que añadir nodos a una subred solo ocasiona que se modifique la máscara de esa subred. Aun más, si una máscara de subred deba cambiar, pero no se pueden reconfigurar todos los nodos al mismo tiempo, es menos dañino que los nodos aun no configurados tengan una máscara demasiado grande (muchos unos) que una demasiado pequeña. Esto se debe a que, con una máscara grande, un nodo puede pensar que otro nodo, que de hecho está en la misma subred, se encuentre en otro segmento. En este caso, el nodo enviara los paquetes al router, el cual los dirigirá hacia el destino. Sin embargo, con una máscara muy pequeña, un nodo puede pensar que su destino, que de hecho está en otro segmento, es local a su subred, e intentara realizar un ARP, que no obtendrá ninguna respuesta (Obsérvese que los mensajes de difusión pueden fallar si las máscaras no coinciden). Finalmente, hacer notar que la subred C necesita tres s-bits en vez de solo dos. Esto se debe a que con dos,la direccion de subred de C sería "11" (En vez de "110") que es el valor reservado para las difusiones. El paso 2 en la rutina AddSubnet comprueba este caso. Ahora se añade una cuarta subred, D, también con 4 nodos. Obtenemos entonces: Subred Dir. Máscara A 10gg ghhh 1111 0000 B 01gg ghhh 1111 0000 C 110g ghhh 1111 0000 D 001g ghhh 1111 0000 Obsérvese que ninguna de las subredes originales ha requerido ningún cambio en sus bits de estado. Esto se debe a que, cuando D compara su direccion con las restantes subredes (Paso 5 de AddSubnet(), usando la mascara-s), todas eran diferentes. En otras palabras, un router pede distinguir las direcciones en D de las direcciones en A, B y C. Añadimos ahora una quinta subred, E. Obtenemos: Subred Dir. Máscara A 100g ghhh 1111 0000 B 01gg ghhh 1111 0000 C 110g ghhh 1111 0000 D 001g ghhh 1111 0000 E 101g ghhh 1111 0000 Esta vez, A ha sido obligada a cambiar el g-bit más a la izquierda (bit 5) a s-bit,porque el bit 5 es necesario para distinguir la subred A de la subred E (Paso 511 de AddSubnet()). Cambiando el bit 5 a s-bit prevenimos que se pueda añadir nodos a A hasta el punto en que el bit 5 cambiara a 1 (Es decir, el paso 5 de AddHost fallaría). Obsérvese también que si las máscaras en A. B y C fueron ajustadas originalmente a 1100.0000, entonces el añadir E habría forzado al cambio de la máscara de A a 1110.000 (Paso 512 de AddSubnet()) A continuación, se añaden 8 nuevos nodos a las subredes A y C, obligando a cambiar el b-bit más a la derecha de ambas redes a cambiar a h-bit. Subred Dir. Máscara A 100g hhhh 1111 0000 B 01gg ghhh 1111 0000 C 110g hhhh 1111 0000 D 001g ghhh 1111 0000 E 101g ghhh 1111 0000 De nuevo las máscaras no han cambiado. Si las máscaras para A, B y C se ajustaron inicialmente a 11111000, entonces si hubiera sido necesario un cambio (Paso 62 de AddHost()). A continuación, se insertan nuevos nodos a la subred B hasta que todos los g- bits son transformados en h-bits. Subred Dir. Máscara A 100g hhhh 1111 0000 B 01hh hhhh 1100 0000 C 110g hhhh 1111 0000 D 001g ghhh 1111 0000 E 101g ghhh 1111 0000 Obsérvese que la máscara en la subred B ha tenido que ser cambiada para acomodar los nuevos h-bits (Paso 62 de AddHost()). Además, si la persona que asigna las direcciones dentro de B (La Autoridad de Direcciones de B) es diferente de la persona que asigna las direcciones de las subredes (ADRaiz), La Autoridad de direcciones de B debe coordinar con la Autoridad de direcciones raíz el cambio del último de los g-bit a h-bit. Esto permite a la Autoridad Raíz asignar correctamente direcciones de subred adicionales, como veremos en el siguiente ejemplo, donde añadiremos una nueva subred F: Subred Dir. Máscara A 100g hhhh 1111 0000 B 01hh hhhh 1100 0000 C 110g hhhh 1111 0000 D 001g ghhh 1111 0000 E 101g ghhh 1111 0000 F 1110 ghhh 1111 0000 La subred F recibió la direccion de 1110, en vez de la 011 (Que es la que viene después de 1010 en la cuenta reflejada). La razón es que 1) 001 no se puede distinguir de la dirección de subred de B usando la máscara de B, y 2) no se puede incrementar el tamaño de la máscara de B, para distinguirlas, porque B ya tiene asignados hosts que usan el bit de la posición 5. En otras palabras, cuando se comparó, en el paso 1 de AddSubnet, el valor 011, ambos valores eran idénticos, así que se intentó con la siguiente dirección. De hecho, no se pueden asignas direcciones de subred con 01 en las posiciones 7 y 8 (a no ser que B pierda nodos). A continuación, eliminamos la red E Subred Dir. Máscara A 10gg hhhh 1111 0000 B 01hh hhhh 1100 0000 C 110g hhhh 1111 0000 D 001g ghhh 1111 0000 F 1110 ghhh 1111 0000 Obsérvese que esto obliga a la subred A a cambiar un bit-s de nuevo a bit-g. Esto se debe a que la igualdad en el paso 33 de RemoveSubnet() no sigue siendo verdadera para la subred A con respecto al resto de subredes. referencias [1] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, USC/Information Sciences Institute, October 1989. [2] Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", RFC 950, USC/Information Sciences Institute, August 1985. [3] Moy, J., "OSPF Specification", RFC 1131, Proteon, October 1989. [4] Postel, J., "Internet Control Message Protocol", RFC 792, USC/Information Sciences Institute, September 1981. [5] Tsuchiya, P., "Efficient and Flexible Hierarchical Address Assignment", TM-ARH-018495, Bellcore, February 1991. [6] Hedrick, C., "Routing Information Protocol" RFC 1058, Rutgers University, June 1988. [7] Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987. Consideraciones de seguridad No se comenta ninguna cuestión relativa a seguridad en este documento. Dirección del autor Paul F. Tsuchiya Bellcore 435 South St.5 South St. MRE 2L-281 Morristown, NJ 07960 Phone: 201 829-4484 EMail: tsuchiya@thumper.bellcore.com