Network Working Group P.

Tsuchiya
Request for Comments: 1219 Bellcore
April 1991

Acerca de la asignacin de Direcciones en sub-redes

(Traduccin al castellano: Noviembre 1999)

(Por: Juan Ignacio Rodriguez de Len <jileon@www.gobcan.es>)

Categora de este Memorandum

Este documento sugiere un nuevo procedimiento para la asignacin de

nmeros IP dentro de subredes. Aplicar esta tcnica dentro de una red es un
asunto puramente local, dado que no tendr ningn efecto sobre otras redes.
Por lo tanto, utilizar o no este procedimiento es totalmente opcional.

Este memorandum proporciona informacin para la comunidad de usuarios de

Internet. No especifica un estndar Internet. No existe ninguna limitacin para
La distribucin de este documento.

Introduccin

El documentos RFC-950 especifica un procedimiento para hacer una sub-red

(subnetting) a partir de una direccin IP, utilizando una mscara de bits.
Aunque esta especificacin permite que los "unos" dentro de la mascara no
sean contiguos, se recomienda: 1) que sean contiguos y 2) que ocupen los bits
ms significativos de la parte "host" de la direccin internet.

RFC-950 no especifica si diferentes subredes dentro de la misma red pueden

o no tener diferentes mscaras. Esta ambigedad ha resultado desafortunada, ya que
ha conducido a un desarrollo de protocolos de rutado que no soportan determinadas
mscaras, por ejemplo RIP [6]. El RFC Requisitos de enrutamiento (Gateway
Requirements) [7] estableci la posibilidad de permitir esta caracterstica, por lo
que se espera de los protocolos ms recientes que soporten esta caracterstica;
OSPF [3] es un ejemplo.

El administrador de la red debe determinar, por supuesto, la mscara de

cada
subred. Esto implica realizar una estimacin del nmero mximo de nodos que tendr
cada
subred. dado que en redes relativamente grandes es prcticamente imposible predecir
como crecer cada subred, a menudo se tomas medidas ineficaces, que producen unas
redes infrautilizadas y otras sobrecargadas, cuyas mquinas 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 tamao de las subredes.
Esencialmente, el mtodo consiste en asignar los bits de la mscara que
pertenecen al "host" (los ceros) desde el bit menos significativo a los ms
significativos, mientras que los bits de la mascara que pertenecen a la subred
se asignan a la inversa, desde el bit ms significativos a los menos. A medida
que aumenta el nmero de subredes, se asigna mas bits a la mscara de subred.
Aunque este proceso implica a veces modifica las mscaras de red, nunca es
necesario cambiar las direcciones de los nodos.

Esta tcnica no es nueva, pero no es muy conocida, y aun menos veces

utilizada. Con el desarrollo de nuevos mtodos de rutado, como OSPF, es posible
sacar el mximo provecho de ella. El propsito de este documento es, por
lo tanto, difundir el conocimiento de esta tcnica, as com especificarla
claramente.

Esta especificacin no requiere ningn cambio en los actuales estndares de

Internet. Si requiere, sin embargo, que los protocolos de rutado intra-dominios
sean capaces de manejar diferentes mscaras 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
comprobacin de los detalles de la especificacin y de los ejemplos.

1. Motivacin

La Norma de subredes, RFC-950. especifica que la parte del nodo de la

direccin
Internet (Formalmente limitada a dos niveles) puede subdividirse en dos campos,
subred y nodo. De esta manera se proporciona a la direccin Internet un tercer
nivel
de jerarqua, lo que facilita una reduccin en la sobrecarga de routers y
cortafuegos.
Tambin incrementa el nivel de ineficiencia en la asignacin de direcciones.

Esta ineficacia proviene de que el administrador normalmente

sobredimensiona el
tamao (nmero de nodos) de las subredes, para prevenir futuras modificaciones
en la estructura de las subredes. Tambin puede ocurrir que el protocolo de
enrutado
utilizado no sea capaz de manejar subredes de tamao diferente, por lo que el
administrador
debe asignar a cada red un tamao equivalente al de la subred ms grande (Este RFC
no
ofrece ninguna ayuda en esta ltimo caso, ya que la tcnica aqu explicada requiere
subredes de diferente tamao).

La carga de trabajo asociada con el cambio de la estructura de subredes de

una red puede
llegar ser considerable. Como ejemplo, considrese 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 seccin de subred (Es decir, la mscara 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 asignacin inicial de

254 nodos.
Lo ideal sera poder cambiar la mscara de la subred B sin tener que hacer ningn
cambio
en las direcciones de las mquinas en dicha red. Sin embargo, los subredes
numricamente
superior e inferior ya estn ocupadas por A y C (Si la direccin 3.0 no estuviera
ocupada por A, se podra cambiar la mscara de B de 255.0 (FF00) a 254.0 (FE00). En
este caso, todas las direcciones actuales de B seguiran encajando en la nueva
subred.
Aun ms, si fuera posible usar mscaras no contiguas, B podra seleccionar otros
bits de la
mscara que podra cambiar a 0. No obstante, las mscaras no contiguas no son
deseables, ya
que imponen ciertas restricciones en determinados algoritmos de bsquedas. 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
mscara de subred menor (Es decir, con menos unos). La primera opcin se puede
realizar fsicamente o lgicamente. Fsicamente, la creacin de las dos subredes
implica la particin de la subred inicial en dos, e insertar entre estos dos nuevos
segmentos un mecanismo de rutado. Por razones obvias, este mtodo dista mucho de
ser el ideal. Lgicamente, 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 mquina en este espacio. El resultado de esta particin lgica es
que los nodos que estn en diferentes subredes no se reconocern como
pertenecientes al
mismo segmento, de forma que enviarn los paquetes al enrutador por defecto, en vez
de enviarlos directamente al destino. En realidad, esta solucin no es tan mala
como podra parecer, ya que si el enrutador es capaz de reconocer mltiples
direcciones
de subred dentro de una subred, puede simplemente enviarle al nodo que envi el
mensaje una Redireccin ICMP [4], de forma que los paquetes siguientes irn
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 direccin de subred a B, lo que implica cambiar las
direcciones
de todas las mquinas conectadas a B, modificar las entradas en el sistema de
nombres de
dominio (DNS), y modificar cualquier fichero de configuracin en cualquier mquina
que
contenga direcciones IP para mquinas en la red B.

2. Una tcnica para asignar direcciones de subred ms flexible y eficiente.

Con vistas a explicar mejor esta nueva tcnica, debemos estudiar

cuidadosamente
los problemas de lo visto hasta ahora. En la actualidad, la mayora de las subredes
se asigna dividiendo la seccin destinada a la mquina de la direccion IP en dos
campos, la subred y la mquina. Los bits de la mscara son unos para indicar el
campo de subred y ceros para indicar el campo de mquina (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 Mquina |
 --------------------------------------

El campo de subred puede ser de diferente longitud segn el tamao de la

misma. Por ejemplo, supongamos que tenemos una red compuesta de dos grandes
subredes (Por grande se debe entender con un gran nmero de mquinas
conectadas) y varias otras redes ms pequeas. El administrador podra asignar
dos tipos de direcciones:

--------------------------------------
| subred | mquina | Subred grande
--------------------------------------

--------------------------------------
| subred | mquina | subred pequea
--------------------------------------

En este caso, la totalidad del rango de direcciones no se podra asignar a

las redes pequeas, ya que los bits en la subred pequea que correspondan con
los de la subred grande no pueden utilizarse en esta. Supongamos, por ejemplo,
que la mscara de la subred grande tiene un ancho de 4 bits, mientras que las
redes pequeas 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 pequeas, ya que de lo contrario habra direcciones que
perteneceran a ambas subredes.

Normalmente, el administrador de la red asignar valores a las dos subredes

en el orden numrico habitual. Por ejemplo, dada una determinada direccin de
subred, las mquinas se numerarn 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
nmero de bits en el lado derecho del campo subred y del campo nodo consistirn
en bits que cambiaran sus valores segn la numeracin de las mquinas, mientras
que ciertos bits situados a la izquierda del campo subred y nodo sern 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 nmero de nodos en una determinada subred crece

hasta el mximo permitido, pero que todava hay espacio en el campo de la subred
para asignar ms direcciones. En este caso, tendramos lo siguiente:

--------------------------------------
| campo subred | campo host |
|-----+-----------+--------------------|
| | | |
| 0 | 1 0 | 1 0 |
 Aunque el campo host ya no puede crecer ms, todava hay espacio disponible
en la direccin para crecer. El problema es que, dada la situacin donde se ha
ubicado el area de crecimiento, este espacio ha quedado reservado solamente para
las subredes.

Lo que podramos haber hecho es asignar los nmeros de las subredes de

forma
que los unos empezaran desde la izquierda del campo subred hacia la derecha. En
esa caso, tendramos 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 ms 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 harn falta, este sistema permite la mxima
flexibilidad en el crecimiento.

En realidad, el esquema anterior es engaoso. El lmite entre los campos de

subred y nodo se muestran en la mitad del rea de crecimiento. Sin embargo, el
lmite puede establecerse en cualquier sitio dentro del rea de crecimiento.
Ntese que es la propia mscara la que determina donde est la frontera. Los
unos de la mscara indican el campo de subred, mientras que los ceros indican
el campo de nodo. Veremos ms adelante que, de hecho, el lmite debe
establecerse en algn sitio cercano a la mitad. En esa situacin se minimiza el
nmero de veces que la mscara debe ser cambiada en los nodos.

2.1 Especificaciones de la nueva tcnica

Una vez visto las explicaciones preliminares, podemos especificar el

procedimiento
para la asignacin 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 ms a la derecha (inclusive). Ntese que diferentes subredes
pueden tener diferentes s-bits.

Bits de crecimiento (g-bits): Son los que llambamos "todo ceros", situados
entre
los h-bits y los s-bits.
 Mscara-S (s-mask): Dada una subred, es aquella mscara donde todos los s-
bits son uno, y todos los g-bits y los h-bits son cero.

Mscara-G (g-mask): Dada una subred, es la mscara donde todos los s-bits y
los g-bits son cero, y todos los h-bits estn a uno.

Campo de subred (Subnet Field): Son los bits que estn a uno en la mscara
de subred (Tal y como se definen en el RFC-950). Estos bits estn a la
izquierda, Los campos de subred deben incluir, como mnimo, todos los s-bits, y
pueden incluir opcionalmente alguno o todos los g-bits.

Campo de nodo (Host Field): Son los bits que estn a cero en la mascara de
subred. Estos bits
estn a la derecha. El Campo de nodo debe incluir, como mnimo, 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 ms significativo es
intercambiado con el menos significativo, el segundo bit ms 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 continuara as. La cuenta reflejada sera:

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 sera

el 101, mientras que el anterior sera 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#).
 Ntese que el algoritmo se describe como si una mquina de estados
estuviera
ejecutndolo. En realidad, debera haber una Autoridad de Direcciones raz
(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 coordinacin entre la Autoridad raz 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 aadido
una nueva subred, en el segundo porque se ha aadido 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, ntese que se usarn las siguientes convenciones, propias del

lenguaje de programacin C.

& funcin AND a nivel de bits

== es igual a
!= es diferente de
x-mask(X) la mscara 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 nmero nunca se asigna a ninguna
subred.

AddSubnet():

1. Encontrar el menor nmero 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 ms 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 ms a la
derecha. Esto previene que utilicemos el valor especial "todo
unos" (utilizado para enviar mensajes a todos los nodos de la
red) como direccin de subred (Dado que no hay ningn nodo
asignado a esta red, el bit que este ms a la derecha y que
valga uno es un bit de subred).

3. Etiquetar los bits restantes de la direccion como g-bits (Por

direccin se debe entender la parte de la direccin IP excluyendo
la parte de red).

4. Ajustar la mscara de subred para que incluya, al menos, todos los

s-bits, y opcionalmente algunos g-bits. La mscara de subred debe
ser contigua (En la seccin 2.2 se explicarn los pros y los contras
de la eleccin de la mscara).

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 ms a la izquierda de Y a s-bit. Si
la administracin raz (ADRaiz) es distinta de la
administracin 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 raz.

512. Expandir la mscara de subred para todos los hosts

en Y si fuera necesario (Es decir, si la mscara de
subred no incluye todos los s-bits)

RemoveSubnet(S):

1. Considerar B como la posicin del s-bit ms a la derecha en S.

2. Borrar S
3. Para todas las subredes Y existentes:
31 Si el bit en la posicin B no es un s-bit, o si el bit en la
posicin B es un uno, o si el bit en la posicin 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 posicin 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 posicin 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 direccin A consistente en la direccin de la subred S

concatenada con ceros.
2. Asignar a A los mismos h-bits, g-bits y s-bits que las dems direcciones
de nodos.
3. Encontrar la direccin de nodo ms pequea, que sea distinta de
cero (usando cuenta normal), y que est sin asignar.
4. Si todos los bits a contar desde el bit ms a la izquierda que valga
uno hasta la posicin 0 son unos, ejecutar los pasos 5 y 6 usando
la posicin B como un bit a la izquierda del bit con valor uno ms
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 posicin B es un s-bit, entonces no se puede aadir el
nodo. Ignorar los pasos siguientes.
6. Si el bit en la posicin B es un g-bit:
61. Cambiar el g-bit a h-bit para todos los nodos de S. Obsrvese
que si fuera el ltimo g-bit, este cambio debera ser coordinado
con la autoridad que asigne las direcciones dentro la subred (ver
seccin 2.2)
62. Modificar la mscara de subred en todos los nodos en que
fuera necesario
7. Crear una nueva direccin 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 ms a la izquierda es cero, y hay un
cero en al menos una de las posiciones a la derecha del h-bit ms a la
izquierda, entonces cambiar el h-bit ms a la izquierda en un g-bit, para todos
los nodos.

Merece la pena hacer notar que esta tcnica en un subconjunto del esquema
de
direccionamiento kampai [5], ms general (nivel n), reducido al nivel 2. La
diferencia principal es que el mtodo general para n niveles conduce a mscaras
no contiguas, mientras que con el nivel 2 no. En la descripcin del mtodo
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 direccin 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. Obsrvese 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 asignacin de subred. los espacios son solo para que los
ejemplos sean ms fciles de leer. Finalmente, numeramos nuestros bits de 0 a 7
desde la derecha hacia la izquierda, tal y como se muestra a continuacin:

Subred Direccin Mscara

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). Obsrvese que hemos elegido las mscaras de forma que haya
espacio de crecimiento tanto para el campo nodo como para el campo subred, sin
necesidad de cambiar la mscara de subred. Sin embargo, hemos permitido un mayor
crecimiento en las subredes que en los nodos, porque aadir nuevas subredes
puede ocasionar cambios de mscara en las subredes existentes, mientras que
aadir nodos a una subred solo ocasiona que se modifique la mscara de esa
subred.

Aun ms, si una mscara de subred deba cambiar, pero no se pueden

reconfigurar todos los nodos al mismo tiempo, es menos daino que los nodos aun
no configurados tengan una mscara demasiado grande (muchos unos) que una
demasiado pequea. Esto se debe a que, con una mscara 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 mscara muy pequea, 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 (Obsrvese que los mensajes
de difusin pueden fallar si las mscaras 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 sera "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 aade una cuarta subred, D, tambin con 4 nodos. Obtenemos

entonces:

Subred Dir. Mscara

A 10gg ghhh 1111 0000
B 01gg ghhh 1111 0000
C 110g ghhh 1111 0000
D 001g ghhh 1111 0000
 Obsrvese que ninguna de las subredes originales ha requerido ningn 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.

Aadimos ahora una quinta subred, E. Obtenemos:

Subred Dir. Mscara

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 ms 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
aadir nodos a A hasta el punto en que el bit 5 cambiara a 1 (Es decir, el paso
5 de AddHost fallara).

Obsrvese tambin que si las mscaras en A. B y C fueron ajustadas

originalmente a 1100.0000, entonces el aadir E habra forzado al cambio de la
mscara de A a 1110.000 (Paso 512 de AddSubnet())

A continuacin, se aaden 8 nuevos nodos a las subredes A y C, obligando a

cambiar el b-bit ms a la derecha de ambas redes a cambiar a h-bit.

Subred Dir. Mscara

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 mscaras no han cambiado. Si las mscaras para A, B y C se

ajustaron inicialmente a 11111000, entonces si hubiera sido necesario un cambio
(Paso 62 de AddHost()).

A continuacin, se insertan nuevos nodos a la subred B hasta que todos los

g-
bits son transformados en h-bits.

Subred Dir. Mscara

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

Obsrvese que la mscara en la subred B ha tenido que ser cambiada para

acomodar los nuevos h-bits (Paso 62 de AddHost()). Adems, 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 raz
el cambio del ltimo de los g-bit a h-bit. Esto permite a la Autoridad Raz
asignar correctamente direcciones de subred adicionales, como veremos en el
siguiente ejemplo, donde aadiremos una nueva subred F:

Subred Dir. Mscara

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 despus de 1010 en la cuenta reflejada). La razn es que 1) 001 no se
puede distinguir de la direccin de subred de B usando la mscara de B, y 2) no
se puede incrementar el tamao de la mscara de B, para distinguirlas, porque B
ya tiene asignados hosts que usan el bit de la posicin 5. En otras palabras,
cuando se compar, en el paso 1 de AddSubnet, el valor 011, ambos valores eran
idnticos, as que se intent con la siguiente direccin. 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 continuacin, eliminamos la red E

Subred Dir. Mscara

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

Obsrvese 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 cuestin relativa a seguridad en este documento.

Direccin 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