¿Las subredes son siempre 1 contiguas? [duplicar]

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) 1s contiguos (bits HI). Por ejemplo, 255.255.0.0( /16) se traduce a los siguientes octetos:

11111111 . 11111111 . 00000000 . 00000000

Yo creo que estos bits deben ser contiguas, porque todo el punto de división en subredes es el ID de host derivar y rangos de ID de dispositivos disponibles. Pero me hace preguntarme, ¿podría alguna vez tener una máscara de subred de, por ejemplo 255.17.255.0, o:

11111111 . 00010001 . 11111111 . 00000000

• ¿Esto pasaría alguna vez? ¿O es imposible que existan subredes sin 1 contiguos? Si es así, ¿por qué?
• De lo contrario, si es posible hacer esto, ¿por qué lo haría (algunos ejemplos concretos)?

La sección 3.1 en el RFC muestra las máscaras permitidas en el enrutamiento entre dominios sin clase. Los bits deben ser contiguos para que la ruta funcione correctamente.

Además, cuando se piensa lógicamente, no tendría sentido tener extrañas máscaras de red aleatorias.

Sí, la forma más fácil de pensarlo es que las máscaras de subred siempre son 1 al comienzo. Si un indicador de tamaño de subred no tiene 1s al comienzo de la representación binaria, entonces diría que el indicador de tamaño de subred no es una "máscara de subred" adecuada, utilizando estándares modernos.

RFC 1219 establece que el RFC 950 anterior permite bits no contiguos. De hecho, RFC 950 página 15 (sección 3) claramente tiene un ejemplo que "ilustra bits de subred no contiguos". Sin embargo, no hay forma de convertir dichas subredes en notación CIDR. La notación de estilo CIDR es lo que IPv6 ha utilizado (en menos desde RFC 1884 página 7 , primera oración de la sección 2.4), por lo que los bits no contiguos nunca fueron ampliamente compatibles con las redes IPv6. El método de RFC 1219 especifica que "los bits de subred (máscara = 1) se asignan desde el bit de trabajo más significativo hacia lo más mínimo ". (La sección 3.1 del RFC 4632 , mencionada por la respuesta de Sami, apunta a un estándar oficial que discute la notación CIDR).

La página 2 del RFC 1878 muestra la notación estándar de "máscara de subred" para todas las subredes IPv4 excepto /0.

Sin embargo, voy a elaborar un poco sobre la respuesta de Sami, analizando el "por qué" (con un ejemplo concreto, ya que la pregunta pedía) ...

Algunos equipos Cisco de nivel profesional admiten algo llamado "máscara comodín", que invierte los bits. Entonces, una subred normal podría estar representada por algo llamado 00000000.00000000.00000000.11111111.

Con las máscaras comodín de Cisco, no había una regla de que todos los ceros tuvieran que ir primero. Para que puedas usar 00000000.00000000.00000000.11111110.

Eso terminaría creando un grupo que contenía todas las direcciones IP pares.

En realidad, era importante saberlo, porque la capacitación de Cisco lo cubría y, por lo tanto, el proceso de examen de las certificaciones profesionales de Cisco podría preguntar sobre tal cosa.

Sin embargo, creo que fue sobre todo inútil. En lugar de dividir una red a la mitad utilizando direcciones pares o impares, puede dividir una red a la mitad utilizando direcciones de números bajos y direcciones de números altos, haciendo subredes normales que sean la mitad de grandes.

Las máscaras comodín con bits no contiguos no eran terriblemente útiles, y podría ser más difícil trabajar con ellas. El punto del bit de máscara de subred establecido en 1 es decir que el bit ayuda a identificar en qué subred se encuentra un dispositivo. No hay una razón convincente para que esos bits se distribuyan por toda la dirección, en lugar de simplemente agruparlos al comienzo de la dirección. . El resultado fue que el soporte de este tipo de máscaras era una complejidad adicional sin muchos beneficios sustanciales.

Supongo que Cisco finalmente acordó que no tiene sentido tales máscaras de subred no tradicionales, porque finalmente dejaron de admitir las "máscaras comodín". Los firewalls Pix más antiguos admiten "máscaras comodín", pero las unidades ASA más nuevas utilizan "máscaras de subred" estándar. .

Ni siquiera trataría de hacer una red con "bits de subred" no contiguos en la máscara, porque una gran cantidad de software seguiría las nuevas tendencias / estándares y rechazaría dicho diseño de red. Incluso si estuviera usando un software anterior, probablemente desearía que mi red pudiera modificarse fácilmente para poder usar un 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 una prueba, me sentiría seguro al decir que todos los 1 deben estar al comienzo de la dirección. Eso es lo que cualquier evaluador cuerdo desearía que la mayoría de los estudiantes aprendan hoy en día.

RFC 950 dice 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)))

así que la propuesta era sobre una operación simple de bits que no se preocupa por 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 encajaría en el tiempo.

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, esas RFC parecen estar desactualizadas. En Windows 7 SP1, por ejemplo, no es posible establecer dicha máscara de subred:

Incluso en Windows XP SP2, esto ya no era posible:

Sin embargo, el clon ReactOS de Windows 98 permite configurar la máscara de red "extraña":

Estoy de acuerdo con la respuesta de @Sami Kuhmonen:

La sección 3.1 en el RFC muestra las máscaras permitidas en el enrutamiento entre dominios sin clase. Los bits deben ser contiguos para que el enrutamiento funcione correctamente. Además, cuando se piensa lógicamente, no tendría sentido tener extrañas máscaras de red aleatorias.

Sin embargo, incluso si no se desea ni se permite, aún es posible definir una máscara de subred de 1 no consecutivos. La razón detrás de esto:
la identificación de la red y la identificación del host se calculan a partir de la dirección IP y la máscara de subred utilizando las operaciones binarias AND y XOR. Todo lo demás es irrelevante.

Lo probé hace años en Win 2000, funciona. Ambas computadoras tenían una máscara 255.160.0.0. Estaban en una LAN sin enrutador, por lo que no puedo decir sobre el comportamiento del enrutador (normalmente puede configurar la máscara del enrutador solo en su interfaz web, que lo rechazará).
Tampoco puede ingresar una máscara de subred 'inválida' en el campo correspondiente de la configuración de red; la GUI se niega a tomarlo. Pero puede hacer trampa al cambiarlo 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.