Request for Comments: 950 J. Postel (ISI) Agosto 1985

Network Working Group
Request for Comments: 950
J. Mogul (Stanford)
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 autocodificació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
mejor manera de asignar los relativamente
dirección local a los números de subred y
tanto, elegimos el esquema con máscara de
más flexible, y aún así no es más costoso
cualquiera de los otros.
Agosto 1985
pocos bits de la
de máquina. Por lo
dirección: es el esquema
de implementar que
Por ejemplo, la dirección de Internet podría interpretarse como:
<número_de_red><número_de_subred><número_de_máquina>
donde el campo <número_de_red> es el definido por IP [3], el campo
<número_de_máquina> ocupa, al menos, 1 bit, y la longitud del
campo <número_de_subred> es constante para una red dada. No se
requiere una estructura adicional para los campos
<número_de_subred> y <número_de_máquina>. Si la longitud del campo
<número_de_subred> 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:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
36.40.0.123
255.255.255.255
ICMP=1
Address Mask Request = AM1
0
0
La pasarela puede en este caso responder directamente a la máquina
solicitante.
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
36.40.0.62
36.40.0.123
ICMP = 1
Address Mask Reply = AM2
0
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:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
0.0.0.0
255.255.255.255
ICMP = 1
Address Mask Request = AM1
0
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
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
Agosto 1985
36.40.0.62
255.255.255.255
ICMP = 1
Address Mask Reply = AM2
0
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:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
36.40.0.123
36.40.0.62
ICMP = 1
Address Mask Request = AM1
0
0
36.40.0.62 debería responder exactamente como en el caso anterior.
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
36.40.0.62
36.40.0.123
ICMP = 1
Address Mask Reply = AM2
0
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
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
Agosto 1985
128.99.4.123
255.255.255.255
ICMP = 1
Address Mask Request = AM1
0
0
La pasarela puede responder directamente a la máquina solicitante.
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
128.99.4.62
128.99.4.123
ICMP = 1
Address Mask Reply = AM2
0
255.255.252.0
En el caso de una estación de trabajo sin disco la máquina envía:
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
0.0.0.0
255.255.255.255
ICMP = 1
Address Mask Request = AM1
0
0
128.99.4.62 oirá el datagrama, y debería responder con este
datagrama:
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
128.99.4.62
255.255.255.255
ICMP = 1
Address Mask Reply = AM2
0
255.255.252.0
Si la difusión no está permitida, 128.99.4.123 envía:
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
128.99.4.123
128.99.4.62
ICMP = 1
Address Mask Request = AM1
0
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
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
Agosto 1985
128.99.4.62
128.99.4.123
ICMP = 1
Address Mask Reply = AM2
0
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:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
192.1.127.19
255.255.255.255
ICMP = 1
Address Mask Request = AM1
0
0
La pasarela puede en este caso responder directamente a la máquina
solicitante.
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
192.1.127.50
192.1.127.19
ICMP = 1
Address Mask Reply = AM2
0
255.255.255.88
En el caso de una estación de trabajo sin disco la máquina envía:
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
0.0.0.0
255.255.255.255
ICMP = 1
Address Mask Request = AM1
0
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
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
Agosto 1985
192.1.127.50
255.255.255.255
ICMP = 1
Address Mask Reply = AM2
0
255.255.255.88
Si la difusión no está permitida, 192.1.127.19 envía:
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
192.1.127.19
192.1.127.50
ICMP = 1
Address Mask Request = AM1
0
0
192.1.127.50 debería responder exactamente como en el caso
anterior.
Dirección origen:
Dirección destino:
Protocolo:
Tipo:
Código:
Máscara:
Mogul & Postel
192.1.127.50
192.1.127.19
ICMP = 1
Address Mask Reply = AM2
0
255.255.255.88
[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/Information Sciences Institute, Octubre 1984.
[3]
Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences 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, Universidad 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]