Resumen

  • El formato de RFC 1897 reunía el ASN del proveedor, parte de la red IPv4 del abonado, el subdominio del sitio y el identificador de interfaz, pero su propia norma advertía que el espacio era temporal y sería recuperado.
  • RFC 2471 trasladó 6bone a 3FFE::/16 con otra jerarquía. La red obtuvo registro, enrutamiento BGP4+ y responsabilidades pTLA sin que esa madurez concediera permanencia.
  • RFC 3701 cerró nuevas asignaciones y fijó el 6 de junio de 2006 como final. La devolución a IANA demuestra que acabó la asignación; no demuestra por sí sola que toda referencia obsoleta desapareciera ese día.

Una coordenada prestada podía llevar tráfico real

RFC 1897 fue explícito donde muchos pilotos son ambiguos. Asignó direcciones para probar prototipos IPv6, permitió encaminarlas dentro del experimento y declaró que no debían circular por Internet para otros fines. También dijo que eran temporales, serían recuperadas y obligarían a renumerar. La cláusula de salida no se añadió después de que surgieran problemas: existía antes de que la dependencia tuviera tiempo de consolidarse.

Que una dirección fuera provisional no la hacía ficticia. Un operador podía configurarla, registrarla, anunciarla, alcanzar otro nodo y sostener una aplicación. Cada paso producía una evidencia distinta. Ninguno convertía una autorización de ensayo en propiedad ni otorgaba continuidad en producción.

El propio número condensaba su contexto. El diseño incorporaba el ASN de 16 bits del proveedor, los 24 bits superiores de la dirección IPv4 enrutable del abonado, un campo de subred de 16 bits y un identificador de interfaz de 48 bits. Si el prefijo IPv4 del sitio era más largo, sus bits restantes ocupaban parte del campo de subred. Cuando existía, una dirección MAC IEEE solía proporcionar la identidad de interfaz.

Era una forma rápida de hacer que el nuevo mundo IPv6 se apoyara en relaciones ya conocidas. Al mismo tiempo, inscribía en la dirección los motivos por los que habría que cambiarla: un nuevo proveedor, otra topología IPv4, un enlace diferente o una arquitectura posterior podían invalidar su derivación.

Cambió el mapa y el experimento tuvo que mudarse

RFC 1884 definió la arquitectura inicial de direcciones IPv6 de 128 bits. RFC 1887 propuso que la jerarquía de asignación reflejara proveedores y topología para contener la carga de enrutamiento. RFC 1897 convirtió esa idea en un formato temporal para pruebas.

La arquitectura general evolucionó. RFC 2374 presentó un formato agregable con niveles TLA, NLA y SLA, una separación entre topología pública y del sitio y nuevos supuestos sobre la interfaz. En consecuencia, RFC 2471 declaró obsoleto RFC 1897 y asignó al 6bone el TLA 0x1FFE, del que resultó 3FFE::/16.

La segunda norma repitió la condición esencial: el nuevo espacio también era temporal, recuperable y sujeto a renumeración. Su jerarquía NLA debía identificar redes de tránsito y sitios finales según la topología de 6bone; dentro del sitio, cada organización decidía. La validez de una dirección bajo ese esquema probaba que encajaba en el ensayo, no que el ensayo se hubiera vuelto definitivo.

RFC 3701 recordó después que la migración desde el primer bloque 5F00::/8 hacia 3FFE::/16 ocurrió con pocos problemas. Esa valoración no debe inflarse. No es un inventario de todos los dispositivos y dependencias, ni una garantía de coste cero. Sí muestra que una red ya utilizada pudo aceptar que su coordenada experimental cambiara cuando cambió la arquitectura que la justificaba.

Gobernar un banco de pruebas no era conceder un título

El 6bone desarrolló prácticas de red reconocibles. RFC 2546 y RFC 2772 hablan de BGP4+, filtros, agregación, DNS, objetos de registro, contactos, políticas de ruta y deberes de los pTLA. Los participantes debían respetar el alcance de los prefijos y corregir fugas o anuncios inadecuados. La participación se describía como voluntaria y benévola, pero las tareas operativas eran concretas.

Esa organización hacía posible aprender. Un objeto de registro declaraba quién respondía por un bloque. Una sesión BGP mostraba un intercambio de información. Una ruta aceptada demostraba una decisión del plano de control. Para probar entrega hacían falta datos de reenvío; para probar servicio, una respuesta y un resultado de aplicación. Ninguna pieza, aislada o reunida, borraba la condición temporal de la asignación.

La secuencia completa evita falsas equivalencias: definición, delegación, configuración, política de ruta, anuncio, reenvío y servicio. La salida añade instalación del reemplazo, actualización de DNS, túneles y controles de acceso, retirada del bloque antiguo y observación independiente de que ninguna referencia vieja sigue controlando algo importante.

El calendario hizo ejecutable la promesa de salida

Cuando las vías de producción para IPv6 ya estaban disponibles, mantener indefinidamente el testbed podía convertir una transición en un sistema paralelo. RFC 3701 detuvo las nuevas asignaciones pTLA el 1 de enero de 2004 y fijó para el 6 de junio de 2006 la retirada. Después, los prefijos de 6bone no debían utilizarse en Internet y los operadores podían filtrarlos. IANA debía recuperar 3FFE::/16.

El plan no transformaba automáticamente una asignación experimental en otra de producción ni prometía un tamaño concreto. Los participantes tenían que acudir a la autoridad correspondiente. También dejó constancia de que el grupo de trabajo anterior ya no tenía 6bone en su mandato y de que la decisión se encauzaba por el proceso IETF. Eso documenta una solución institucional; no es prueba de consentimiento individual de todos los participantes.

RFC 5156 registró más tarde que 5F00::/8 y 3FFE::/16 habían vuelto a IANA y no debían aparecer en la Internet pública salvo una futura reasignación. El registro superior quedó cerrado. Pero un asiento administrativo no barre por sí mismo literales en código, reglas de firewall, entradas DNS o cuadernos de operaciones. La devolución del recurso y la eliminación de sus dependencias son dos verificaciones distintas.

Fuentes