Resumen

  • RFC 3091 pidió que un proveedor multicast enviara dígitos de pi al grupo 314.159.265.359, que no es una dirección multicast IPv4 válida.
  • Sus puertos TCP y UDP distintivos, 314159 y 220007, también superaban los 16 bits del campo de transporte; tal como estaban escritos, no podían codificarse en la red.

La propuesta parece sencilla si uno empieza por su propósito. Una estación de trabajo sin capacidad local para generar los dígitos de pi podía conectarse a un servidor y recibirlos, pedir uno concreto por su posición o escuchar una difusión multicast. En esta última variante, un proveedor enviaría dígitos elegidos al azar para que los receptores construyeran con el tiempo un valor coherente. La arquitectura ofrece tres formas de intercambio, pero cada una depende primero de que sus identificadores puedan representarse en los campos reales de la red.

El diseño multicast deja ver la fisura con claridad. RFC 3091 asigna al grupo la cadena 314.159.265.359. Una dirección IPv4 en notación decimal separada por puntos tiene cuatro octetos, cada uno entre 0 y 255; RFC 1112 sitúa los grupos IPv4 entre 224.0.0.0 y 239.255.255.255. La cadena del RFC contiene cinco componentes, y el primero ya supera el límite. No es un grupo multicast válido que simplemente esté pendiente de asignación. No puede nombrar un grupo IPv4 al que un host pueda unirse.

Los puertos fallan por el mismo motivo. RFC 793 define los puertos de origen y destino de TCP como campos de 16 bits; RFC 768 hace lo mismo con UDP. El valor máximo sin signo es 65.535. Sin embargo, el servicio TCP requerido por RFC 3091 debía escuchar en el puerto 314159; el servicio UDP opcional reutilizaba ese número. Las variantes aproximadas para 22/7 señalaban el puerto 220007. Ninguno cabe en un puerto TCP o UDP. RFC 6335 organiza las asignaciones de la IANA dentro del espacio que esos campos pueden representar; registrar un número no amplía el campo.

La contradicción no es un detalle cosmético. El servicio TCP proponía que el servidor transmitiera dígitos sin límite hasta que el cliente cerrase la conexión. Por UDP, el cliente consultaría el enésimo dígito y recibiría una respuesta indexada. El multicast eliminaba la consulta: un proveedor aguardaba treinta segundos sin detectar otro proveedor, comenzaba a emitir una distribución aleatoria y los clientes reunirían los dígitos con el tiempo. El texto especificaba comportamientos diferentes en cada capa, pero el primer paso operativo consistía siempre en llegar a un destino que el protocolo no podía codificar.

El documento lleva fecha del 1 de abril de 2001 y categoría Informational. IETF Datatracker lo ubica en la vía de Independent Submission y aclara que la IETF no lo respalda y que no forma parte de su proceso formal de estándares. La fecha, los números imposibles de codificar y la advertencia de que Internet colapsaría pronto sin servidores de pi confiables hacen que se lea como una broma. Esa es una interpretación contextual sólida, no una prueba independiente de la intención privada del autor.

El hecho que deja el archivo es más acotado: un documento publicado como RFC describió un protocolo cuyas direcciones no cabían en los protocolos que pretendía usar.

El número del RFC tampoco demuestra que hubiese una implementación. El registro documenta el texto y su vía de publicación; no prueba que un host escuchara en ese puerto, que existiera el grupo multicast, que alguien corrigiera las constantes para un despliegue o que clientes recomponían pi en una red real. La referencia a métodos de cálculo y a la localización mediante DNS SRV aporta detalles, pero no corrige el tamaño de los campos. SRV puede anunciar un puerto; el transporte aún debe poder llevarlo.

RFC 3091 conserva una lección concreta de la historia de la ingeniería de Internet: una descripción puede parecer completa y fallar al convertir nombres en representaciones sobre el cable. Que un puerto recuerde a pi o que una cadena de dirección imite una secuencia numérica no la convierte en un identificador de red. Antes de discutir descubrimiento de servicios, balanceo de carga o convergencia de receptores, hay que comprobar primero si los bits pueden representar el destino.

Fuentes