Resumen

  • El 9 de junio de 1996, WIDE registró su primer trayecto IPv6 de ida y vuelta entre el Instituto de Ciencia y Tecnología de Nara y su NOC de Tokio. Usó un enlace serie, no un túnel IPv6 sobre IPv4.
  • WIDE dividió un T1 entre 1.472 kbps para IPv4 y 64 kbps para IPv6; su retrospectiva dice que así evitó pagar otra línea arrendada y separó la operación de ambas redes.

El primer paquete tomó una ruta estrecha

El inicio de WIDE 6bone no fue una versión pequeña de la posterior superposición mundial de túneles. Según el relato de WIDE, el primer paquete IPv6 hizo el viaje de ida y vuelta entre Nara y Tokio a las 15:22, hora de Japón, el 9 de junio de 1996, por una conexión serie. El equipo dividió un T1 ya disponible: dejó 1.472 kbps para la red IPv4 habitual y asignó 64 kbps a IPv6. Sus autores señalan dos motivos prácticos: no pagar otra línea arrendada y evitar que la prueba de IPv6 afectara la operación de IPv4. Es la intención declarada por WIDE, no una medición que garantice aislamiento perfecto o velocidad para usuarios.

El arreglo también muestra que un protocolo nuevo podía empezar como servicio local acotado antes de depender de un túnel a través de Internet. WIDE cuenta que la Universidad de Tokio se conectó al NOC de Tokio ese mismo día y que la Universidad de Osaka se sumó una semana después. Al principio usaron direcciones IPv6 compatibles con IPv4 por conveniencia y configuraron rutas manualmente porque aún no había demonios de enrutamiento disponibles.

Los enlaces locales se incorporaron a una red de pruebas global

En la reunión de 6bone de junio de 1996, durante el IETF 36 en Montreal, WIDE dice que hubo acuerdo para establecer un 6bone mundial el 15 de julio. Antes de esa fecha, el equipo cambió las direcciones IPv4-compatibles por las direcciones de prueba IPv6 entonces vigentes. Cisco fue su primer par el 16 de julio. Dos días después, WIDE añadió un túnel IPv6 sobre IPv4 con G6. La secuencia separa hitos: el primer trayecto local de WIDE usó un enlace serie; el túnel posterior unió el sitio con otro participante de 6bone.

El crecimiento produjo otro problema operativo. WIDE relata que las rutas estáticas se volvieron difíciles de mantener a medida que aumentaban los participantes, por lo que instaló RIPng en febrero de 1997. Seis meses después, el informe registraba más de diez saltos dentro de la red de WIDE y 300 rutas completas en el 6bone mundial. Son cifras de una retrospectiva de participante, no un censo completo. Las actas del grupo IPv6 de RIPE informaron por separado de más de 120 sitios conectados en 30 países en una reunión anterior; el proyecto amplio ya tenía alcance geográfico.

También cambiaron las direcciones y el enrutamiento

WIDE no mantuvo un único plan de direcciones ni un único protocolo de enrutamiento durante sus primeros años. Según su informe, una reunión del IETF en Múnich en agosto de 1997 decidió dos cambios operativos: renumerar desde direcciones basadas en proveedor al nuevo formato agregable y migrar a BGP4+ antes del 1 de noviembre. WIDE fue elegido como pseudoagregador de nivel superior y recibió 3ffe:500::/24; volvió a numerar en octubre. BGP4+ llegó en enero de 1998, más tarde de lo previsto, porque se retrasó el desarrollo del demonio.

La transición concuerda con la condición de las direcciones. RFC 1897 describió las primeras direcciones de prueba IPv6 como temporales y anticipó la renumeración. RFC 2471 asignó después espacio de prueba para 6bone bajo el mismo principio temporal. Estos documentos establecen que los prefijos de prueba no eran prefijos de producción permanentes; no verifican por separado las fechas locales de WIDE. RFC 2772 también describía 6bone como una red de pruebas operativa, con un registro, reglas de enrutamiento y requisitos de experiencia para ciertos solicitantes de pTLA.

Por eso, el caso de WIDE es más específico que decir que IPv6 «usaba túneles». Una fracción de 64 kbps de un T1 existente bastó para iniciar una red local. El peering, un túnel, los cambios de direcciones y un nuevo demonio de enrutamiento llegaron a medida que el trabajo se amplió. El relato respalda esa secuencia para WIDE; no demuestra que todos los participantes tuvieran las mismas conexiones, presupuesto o camino de adopción.

Fuentes

  • Grupo IPv6 de WIDE, “Deployment and Experiences of WIDE 6bone”: informe de participantes.
  • Robert Hinden y Jon Postel, RFC 1897, “IPv6 Testing Address Allocation”: RFC.
  • Robert Hinden, Robert Fink y Jon Postel, RFC 2471, “IPv6 Testing Address Allocation”: RFC.
  • Rob Rockell y Robert Fink, RFC 2772, “6Bone Backbone Routing Guidelines”: RFC.
  • Robert Fink y Robert Hinden, RFC 3701, “6bone Phaseout Plan”: RFC.
  • Actas del grupo IPv6 de RIPE 28: registro de reunión.
  • Heng Lu, Nota 64, usada solo como lente editorial: nota.