Resumen

  • El RFC informativo 1375, escrito por Paul Robinson en octubre de 1992, planteó las clases F, G, H y K para que una instalación pequeña no necesitara un bloque de clase C entero.
  • El documento también tanteó códigos regionales y categorías de equipos, pero condicionó su compatibilidad a routers, puentes y software; además, la definición escrita y el diagrama de clase K discrepan.

El tamaño mínimo podía sobrar

El problema descrito en RFC 1375 no era solo que IPv4 tuviera 32 bits. Las clases ofrecían tamaños fijos que podían resultar desproporcionados. Según el memo, una red C admitía hasta 254 direcciones locales; una instalación con cuatro o cinco equipos podía desaprovechar más de 240. El autor anticipaba más redes pequeñas, BBS accesibles por Telnet o FTP y hasta impresoras, fax y buscapersonas conectados a protocolos de Internet.

La solución de Paul Robinson consistía en redistribuir los primeros bits. Parte del espacio de clase C se reservaría para cuatro etiquetas nuevas, F, G, H y K, con campos locales cada vez menores. F se destinaba a sitios de aproximadamente 1 a 15 direcciones conectadas; H, a los que no esperaran superar siete; K, a los que necesitaran una o dos. Eran tamaños ligados a clases fijas, no una invitación general a elegir cualquier longitud de prefijo.

El estado del RFC limita lo que se puede afirmar. RFC 1375 es Informational y declara que no establece un estándar de Internet. Su resumen admite que todavía podría no existir el método necesario para implementarlo y aun así sugiere reservar el espacio. Por tanto, el documento acredita una propuesta, no una asignación ni una red en funcionamiento.

La compatibilidad no se resolvía al reservar bits

El memo impuso una condición explícita: la idea no debía causar problemas si puentes, routers y otros sistemas no suponían que los ocho últimos bits eran siempre la dirección local y aceptaban campos locales más pequeños. Esa salvedad convierte una decisión de asignación en una cuestión de compatibilidad general. El bloque pequeño solo sirve cuando los equipos que configuran y encaminan el tráfico interpretan sus bits de la misma manera.

El texto añade dos ideas optativas. Algunos bits podrían funcionar como códigos de región, inspirados en la marcación telefónica internacional. Robinson aclara, sin embargo, que las direcciones IP no indican por naturaleza una ubicación geográfica y que esos códigos no son imprescindibles para encaminar tráfico. Las notas incluso sugieren dígitos para identificar buscapersonas, fax, pasarelas u otros dispositivos. Son posibilidades especulativas del memo, no funciones documentadas de la Internet desplegada.

La propia clase K deja ver un problema de especificación. La prosa indica un prefijo de siete bits, 1101111, seguido de un campo de red de 25 bits y uno local. El dibujo que sigue muestra otra secuencia (110100) y un campo de red de 26 bits. No es posible leer ambos como una misma disposición. La contradicción aparece en el RFC publicado; las fuentes consultadas no demuestran que alguien implementara la propuesta ni que este detalle determinara su trayectoria.

De clases nuevas a prefijos de longitud variable

En el mismo periodo se publicaron otras respuestas a las presiones de numeración y enrutamiento. RFC 1338 propuso asignación jerárquica a proveedores y supernetting. RFC 1366 abordó cómo distribuir la función registral y los números de red. En septiembre de 1993, RFC 1519, de la serie Standards Track, presentó CIDR: asignaciones orientadas a máscaras de longitud variable, a menudo tomadas del bloque de un proveedor, junto con agregación de rutas. El documento subrayó que asignación y cambios en los protocolos de enrutamiento debían desplegarse conjuntamente para que la agregación funcionara.

Este diseño no necesitaba que cada dirección anunciara una clase con nombre ni una geografía o tipo de dispositivo. La frontera útil pasó a ser la longitud del prefijo. En 1995, RFC 1812 exigió que los routers IPv4 admitieran subredes y CIDR; RFC 1878 enumeró subredes de longitud variable hasta rutas de host. Esos documentos permiten seguir el lenguaje normativo posterior. No prueban que CIDR desplazara directamente a RFC 1375 ni explican por qué la propuesta de Robinson no continuó hacia la estandarización.

La Nota 48 de Heng Lu orienta la lectura, no aporta evidencia sobre 1992: invita a tratar la dirección IP como una etiqueta numérica única cuyos registros deben ser coherentes. La pregunta editorial es qué conviene codificar en esa etiqueta y qué debe resolverse en registros de asignación, máscaras, protocolos de enrutamiento o nombres de aplicaciones. RFC 1375 asignaba a los bits varias capas de significado; CIDR se concentró después en prefijos variables y agregación. La diferencia estaba en dónde recaía el trabajo de interpretar la dirección.

Fuentes