Resumen

  • RFC 1219 hacía crecer los números de subred desde los bits más significativos y los números de host desde los menos significativos. Los bits vacíos del centro quedaban como reserva para cualquiera de los dos lados.
  • El procedimiento podía conservar cada dirección existente, pero al crecer podía exigir máscaras nuevas, rutas capaces de distinguirlas y coordinación entre la autoridad raíz y la autoridad de cada subred.
  • Una máscara antigua demasiado larga enviaba tráfico local hacia el gateway; una demasiado corta provocaba ARP para una máquina remota. La estabilidad del inventario podía ocultar tanto un desvío como una pérdida de conectividad.

Crecer desde extremos opuestos

RFC 1219 se publicó en abril de 1991 con P. F. Tsuchiya como autor. El catálogo del RFC Editor la identifica como Informational. El propio documento define el mecanismo como una decisión puramente local y discrecional, no como un estándar de Internet; la ficha del IETF Datatracker no añade pruebas de uso real.

La máscara ya era una pieza conocida. RFC 950 había formalizado el uso de bits contiguos de subred en la zona más significativa de la parte local de una dirección. El dilema aparecía al reservar el resto: ¿harían falta muchas subredes pequeñas o unas pocas con muchos hosts?

RFC 1219 evitó pronosticarlo. Conservó la numeración ordinaria para los hosts, que ocupa bits desde la derecha. Para las subredes empleó un conteo en imagen especular: sus unos se acumulan desde la izquierda. En medio quedan los g-bits, ceros que representan capacidad aún no comprometida.

Cuando aumentan los hosts, el campo de host absorbe un g-bit. Cuando nace otra subred, el campo de subred absorbe uno desde el otro lado. Como los valores existentes ya ocupan sus extremos, las direcciones asignadas no necesitan cambiar.

El ahorro es concreto. Pero no equivale a congelar la estructura. La misma dirección puede quedar bajo una frontera distinta, y la frontera que un host utiliza está codificada en su máscara.

El nuevo límite necesitaba distribución

Crear una subred puede convertir un g-bit en bit de subred y obligar a ampliar la máscara de una subred previa. Aumentar el número de hosts puede convertirlo en bit de host y exigir que todas las máquinas de esa subred reduzcan sus máscaras. RFC 1219 preserva las direcciones, no todos los parámetros que hacen funcionar esas direcciones.

La exigencia de encaminamiento tampoco era abstracta. RFC 1009 admitía múltiples máscaras en una red dividida en subredes y requería configurar una máscara diferente por interfaz de gateway. Por eso RFC 1219 declara necesario un protocolo intradominio que maneje máscaras distintas.

Soportar una función no demuestra haberla activado. La máscara calculada puede no llegar al host. El gateway puede conservar otro valor. El anuncio puede circular sin converger. Una prueba histórica rigurosa tiene que separar el algoritmo, la configuración aplicada, el estado del protocolo, el recorrido observado y el resultado de la aplicación.

La reserva también repartía autoridad

El documento llama RootAA a la autoridad que asigna subredes. Dentro de cada una, una autoridad local reparte los hosts. Con varios g-bits libres, ambas pueden trabajar casi de forma independiente porque toman capacidad desde lados opuestos.

La independencia termina con el último g-bit. Usarlo para otra subred impide usarlo para ampliar hosts; entregarlo a los hosts cancela la futura subred que habría cabido allí. La RFC exige que las dos autoridades se coordinen en ese punto.

La escasez compartida transforma una operación técnica en una decisión de control. RootAA ve la demanda del conjunto; la autoridad local conoce la saturación de su segmento. Si sus registros tienen versiones diferentes, cada una puede ejecutar una asignación internamente válida y producir en conjunto una colisión.

No conviene convertir los nombres del modelo en una historia de implantación. Las fuentes no identifican a un operador que estableciera esas oficinas, ni una aprobación, una orden de cambio o una propagación completa. La coordinación descrita es una condición del algoritmo; la coordinación realizada necesitaría su propio expediente.

Dos máscaras antiguas, dos fallos distintos

La parte más reveladora de RFC 1219 no es la numeración sino la transición.

Si una máquina conserva demasiados unos en la máscara, considera remota una dirección que en realidad está en su enlace. Entrega el paquete al gateway. Este quizá lo reenvíe al mismo enlace y envíe un ICMP Redirect. Puede haber conectividad, pero con un trayecto innecesario. La mera posibilidad del redirect no demuestra que se emitió, que el host lo aceptó o que corrigió futuras decisiones.

Si la máquina conserva pocos unos, incorpora una dirección remota a su supuesto ámbito local. Hace ARP por ella en vez de consultar al gateway. El destino remoto no oye esa petición local, así que no responde. También pueden fallar los broadcasts cuando las máscaras no coinciden.

Las dos máquinas mantienen su dirección original. Un panel basado en activos no muestra cambios. Sin embargo, una ruta da un rodeo y la otra se queda sin salida. La conservación del identificador es compatible con una red partida en interpretaciones diferentes.

Los ejemplos del documento explican cómo se comporta su modelo; no son capturas de una red desplegada. No certifican que una transición acabó, que hubo convergencia ni que los usuarios conservaron el servicio.

Preservar no es demostrar

RFC 1219 afirmaba que el método era poco conocido y aún menos implementado en 1991. La frase no es una serie estadística ni permite concluir cuál fue su uso posterior. En estas fuentes no hay software, informe de operador o medición de tráfico.

La sección de seguridad dice que no trata el asunto. Por tanto, no respalda autenticación de órdenes, autorización para gastar el último bit, integridad de la distribución ni un rollback seguro.

Lo que sí deja es un método de lectura. La dirección pertenece al inventario; la máscara, a la interpretación local; la ruta, al plano de control; la entrega, a los paquetes; el resultado, al servicio. Que la primera columna no cambie no autoriza a rellenar las demás con «estable».

Fuentes