Resumen

  • RFC 1924 codificó los 128 bits de una dirección IPv6 como un entero en base 85 y obtuvo una cadena fija de veinte caracteres. Era una conversión completa y reversible, no una garantía de interoperabilidad de extremo a extremo.
  • La reserva de nueve signos revela que la dirección comparte espacio con citas, listas, rutas, sufijos CIDR, URL, delimitadores y escapes. La gramática anfitriona también forma parte del diseño.
  • La trayectoria posterior conservó el hexadecimal con dos puntos, añadió corchetes en los URI y definió una salida canónica. Hizo visible la igualdad textual sin convertirla en prueba de asignación, control, ruta o entrega.

Los caracteres que no entraron explican el sistema

RFC 1924 apareció el 1 de abril de 1996 como documento Informational, no como estándar de Internet. Tomó la dirección IPv6 completa como un número sin signo y propuso un alfabeto de 85 caracteres ASCII imprimibles. La dirección 1080:0:0:0:8:800:200C:417A pasaba a ser 4)+k&C#VzJ4br>0wv%Yp. Todas las salidas medían veinte posiciones y conservaban los ceros iniciales.

La base tenía una justificación exacta. El espacio de IPv6 contiene (2^{128}) valores. Veinte dígitos de base 84 no alcanzan, mientras que veinte de base 85 sí: (84^{20} < 2^{128} \leq 85^{20}). Usar 94 o 95 símbolos tampoco reduciría la longitud. La base 85 ofrecía así la anchura fija mínima y dejaba nueve signos para el entorno.

Esos nueve signos eran una lista de conflictos evitados. Las comillas encierran cadenas; la coma separa elementos; el punto termina frases; la barra introduce prefijos y rutas; los dos puntos ya pertenecen a sintaxis de URL; los corchetes pueden delimitar literales; la barra inversa escapa. La compresión era local, pero el texto tenía que convivir con correo, prosa, comandos y protocolos.

La elección fue inteligente incluso como broma. También mostró el límite: reservar separadores reduce colisiones, pero no hace que cada programa reconozca el nuevo interior. Para eso se necesita código desplegado, reglas de almacenamiento, indexación y hábitos de lectura.

Reversible no significa visible

Un decodificador correcto podía reconstruir los mismos 128 bits. Sin embargo, un operador que buscara la forma hexadecimal no hallaría la cadena de base 85. Un inventario que comparara texto podría duplicar un activo. Un analizador sin el nuevo alfabeto vería puntuación, no una dirección. Un informe podía conservar un valor perfecto y romper la correlación con otro informe igualmente perfecto.

La diferencia importa porque el trabajo operativo rara vez comienza con el entero binario. Comienza con copiar, pegar, buscar, ordenar, agrupar y reconocer. La representación funciona como evidencia compartida antes de convertirse en valor de máquina. Cuanto más especial es el formato, más autoridad se entrega a los decodificadores que lo conocen.

El hexadecimal anterior tampoco era único. La arquitectura original permitía ocho grupos de 16 bits, eliminar ceros iniciales, comprimir una sola secuencia de grupos nulos mediante :: y terminar con decimales IPv4. Una misma dirección tenía varias grafías legales. La familiaridad evitaba una ruptura de alfabeto, pero la flexibilidad creaba sus propios fallos de búsqueda.

Un par de corchetes resolvió un conflicto concreto

Cuando una dirección IPv6 debía aparecer como literal en una URL, los dos puntos chocaban con la sintaxis exterior. RFC 2732 no reemplazó la dirección: la encerró entre corchetes. Su objetivo incluía copiar y pegar con una edición mínima, y documentó implementaciones en versiones IPv6 de Internet Explorer, Mozilla y Lynx. RFC 3986 mantuvo después el IP-literal entre corchetes.

La solución es reveladora por su tamaño. Se añadió un límite compartido donde existía la ambigüedad, mientras el interior conservaba una forma que las herramientas ya entendían. El cambio no probaba adopción universal, pero reducía la cantidad de componentes que debían aprender un nuevo contrato.

RFC 4291 conservó las formas hexadecimales flexibles. Esa continuidad permitió aceptar entradas históricas, aunque todavía dejaba a los emisores producir cadenas distintas. El siguiente paso no fue maximizar la compresión, sino acordar cómo escribir.

La salida canónica protegió la comparación

RFC 5952 enumeró problemas observados en búsquedas, hojas de cálculo, archivos de texto, Whois, diagramas, registros, auditorías y verificaciones. Propuso que los analizadores aceptaran todas las formas legales de RFC 4291, pero que los formateadores emitieran una forma recomendada.

La salida eliminaba ceros iniciales, usaba hexadecimal en minúsculas, aplicaba :: a la secuencia nula más larga, escogía la primera si había empate y no comprimía un único grupo cero. No toda dirección quedaba reducida al mínimo imaginable. En cambio, dos sistemas podían producir la misma cadena y facilitar que una búsqueda encontrara ambos registros.

Aceptar mucho y emitir una sola forma distribuye responsabilidades con cuidado. El borde no rompe entradas válidas. El centro deja una evidencia comparable. La normalización no borra la necesidad de guardar la fuente cuando una auditoría debe explicar cómo llegó el dato.

La cadena no demuestra el mundo

Hay al menos seis capas: bits, valor analizado, presentación normalizada, texto guardado, resultado de búsqueda y observación de red. La equivalencia en una capa no asciende por sí sola a la siguiente. Dos cadenas que producen el mismo entero son equivalentes como representación. Una cadena canónica en un registro demuestra que un componente la escribió. No demuestra que la dirección pertenezca a alguien, que un origen de ruta esté autorizado, que exista una ruta activa, que la interfaz responda, que el servicio esté autenticado o que un paquete haya sido entregado.

La fuente histórica está en RFC 1884, RFC 1924, RFC 2732, RFC 3986, RFC 4291 y RFC 5952. No ofrecen un censo que permita afirmar cero implementaciones de base 85 ni dicen que los textos posteriores la rechazaran formalmente.

Running-Code Primacy permite leer el episodio desde el comportamiento real de analizadores, registros y flujos de trabajo. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption explica por qué un núcleo común pequeño puede dejar decisiones locales sin romper la coordinación. Son marcos posteriores, no intenciones atribuidas a los autores de las RFC.

RFC 1924 consiguió veinte caracteres. Lo difícil seguía siendo conseguir que cada sistema y cada persona vieran en ellos la misma prueba.