Entiendo la premisa básica detrás de las máscaras de subred, como 255.255.255.0
. Pero todos los ejemplos de subred que he visto han sido (de izquierda a derecha) 1 contiguos (bits HI). Por ejemplo, 255.255.0.0
( /16
) se traduce en los siguientes octetos:
11111111 . 11111111 . 00000000 . 00000000
Icreerque estos bitsdebeser contiguos, porque el objetivo de la división en subredes es derivar la ID del host y los rangos de ID de los dispositivos disponibles. Pero me hace preguntarme si alguna vez tendrá una máscara de subred de, digamos, 255.17.255.0
o:
11111111 . 00010001 . 11111111 . 00000000
- ¿Sucedería esto alguna vez? ¿O es imposible que existan subredes sin unos contiguos? Si es así, ¿por qué?
- De lo contrario, si es posible hacer esto, ¿por qué lo harías (algunos ejemplos concretos)?
Respuesta1
La sección 3.1 delRFCmuestra las máscaras permitidas en el enrutamiento entre dominios sin clases. Los bits deben ser contiguos para que el enrutamiento funcione correctamente.
Además, cuando se piensa lógicamente, no tendría sentido tener máscaras de red aleatorias extrañas.
Respuesta2
Sí, la forma más sencilla de verlo es que las máscaras de subred siempre son unos al principio. Si un indicador de tamaño de subred no tiene unos al inicio de la representación binaria, entonces diría que el indicador de tamaño de subred no es una “máscara de subred” adecuada, según los estándares modernos.
RFC 1219establece que el RFC 950 anterior permite bits no contiguos. De hecho,RFC 950 página 15(sección 3) tiene claramente un ejemplo que "ilustra bits de subred no contiguos". Sin embargo, no hay forma de convertir dichas subredes a notación CIDR. La notación de estilo CIDR es lo que IPv6 ha utilizado (al menos desdeRFC 1884 página 7, primera frase de la sección 2.4), por lo que los bits no contiguos nunca fueron ampliamente compatibles con las redes IPv6.RFC 1219El método de especifica que "los bits de subred (máscara = 1) se asignan desde el bit más significativo hacia el menos".RFC 4632 sección 3.1, mencionado en la respuesta de Sami, apunta a un estándar oficial que analiza la notación CIDR).
RFC 1878 página 2muestra la notación estándar de “máscara de subred” para todas las subredes IPv4 excepto /0
.
Sin embargo, voy a desarrollar un poco la respuesta de Sami, analizando el “por qué” (con un ejemplo concreto, como pedía la pregunta)...
Algunos equipos Cisco de nivel profesional admiten algo llamado “máscara comodín”, que invierte los bits. Entonces, una subred normal podría representarse con algo llamado 00000000.00000000.00000000.11111111
.
Con las máscaras comodín de Cisco, no había una regla que obligara a que todos los ceros tuvieran que ir primero. Entonces podrías usar 00000000.00000000.00000000.11111110
.
Eso terminaría creando un grupo que contuviera todas las direcciones IP pares.
En realidad, era importante saber esto, porque la capacitación de Cisco lo cubría y, por lo tanto, el proceso de examen para las certificaciones profesionales de Cisco podría preguntar sobre tal tema.
Sin embargo, creo que fue prácticamente inútil. En lugar de dividir una red por la mitad usando direcciones pares o impares, podría simplemente dividir una red por la mitad usando direcciones con números bajos y direcciones con números altos, creando subredes normales que sean la mitad de grandes.
Las máscaras comodín con bits no contiguos no eran muy útiles y podría resultar más difícil trabajar con ellas. El objetivo del bit de máscara de subred establecido en 1 es decir que ese bit ayuda a identificar en qué subred se encuentra un dispositivo. No hay ninguna razón convincente para tener esos bits distribuidos por toda la dirección, en lugar de simplemente agruparlos agradablemente al comienzo de la dirección. . El resultado fue que soportar este tipo de máscaras suponía una complejidad añadida sin muchos beneficios sustanciales.
Supongo que Cisco finalmente estuvo de acuerdo en que no tenían sentido estas máscaras de subred no tradicionales, porque eventualmente dejaron de admitir "máscaras comodín". Los firewalls Pix más antiguos admiten "máscaras comodín", pero las unidades ASA más nuevas usan "máscaras de subred" estándar en su lugar. .
Ni siquiera intentaría crear una red con “bits de subred” no contiguos en la máscara, porque mucho software seguiría las tendencias/estándares más nuevos y rechazaría ese diseño de red. Incluso si estuviera usando software más antiguo, probablemente quisiera que mi red pudiera modificarse fácilmente para poder usar software más nuevo sin necesidad de rediseñar la red. Por lo tanto, los “bits de subred” contiguos son el único camino a seguir.
Si le hacen la pregunta en un examen, me sentiría seguro al decir que todos los 1 deben estar al comienzo de la dirección. Eso es lo que cualquier evaluador en su sano juicio querría que la mayoría de los estudiantes aprendieran hoy en día.
Respuesta3
RFC 950dice en el capítulo 2.2:
To support subnets, it is necessary to store one more 32-bit
quantity, called my_ip_mask. This is a bit-mask with bits set in
the fields corresponding to the IP network number, and additional
bits set corresponding to the subnet number field.
The code then becomes:
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)))
entonces la propuesta trataba sobre una operación de bits simple que no se preocupa por los bits contiguos.
En 1985, la CPU y la memoria eran mucho más limitadas, por lo que cualquier operación más compleja simplemente no cabía en ese momento.
Se vuelve aún más explícito en el capítulo 3:
y que en la red se utiliza un campo de subred de 3 bits (01011000), es decir, la máscara de dirección es 255.255.255.88.
Sin embargo, esos RFC parecen estar desactualizados. En Windows 7 SP1, por ejemplo, no es posible configurar dicha máscara de subred:
Incluso en Windows XP SP2 esto ya no era posible:
El clon de Windows 98, ReactOS, sin embargo, permite configurar la máscara de red "extraña":
Respuesta4
Estoy de acuerdo con la respuesta de @Sami Kuhmonen:
La sección 3.1 del RFC muestra las máscaras permitidas en el enrutamiento entre dominios sin clases. Los bits deben ser contiguos para que el enrutamiento funcione correctamente. Además, cuando se piensa lógicamente, no tendría sentido tener máscaras de red aleatorias extrañas.
Sin embargo, incluso si no se desea o no se permite, aún es posible definir una máscara de subred de unos no consecutivos. La razón detrás de esto:
la ID de red y la ID de host se calculan a partir de la dirección IP y la máscara de subred mediante las operaciones binarias AND y XOR. Todo lo demás es irrelevante.
Lo probé hace años en Win 2000 y funciona. Ambas computadoras tenían una máscara 255.160.0.0. Estaban en una LAN sin enrutador, por lo que no puedo informar sobre el comportamiento del enrutador (normalmente puede configurar la máscara del enrutador solo en su interfaz web, lo que la rechazará).
Tampoco puede ingresar una máscara de subred "no válida" en el campo correspondiente de la configuración de red; la GUI se niega a aceptarlo. Pero puedes hacer trampa cambiándolo directamente en el registro. Luego reinicie o deshabilite+habilite la NIC para que los cambios se activen.
El propósito de todo eso: uhm, probablemente ninguno.