Resumen

  • RFC 2185 mantuvo separados los cálculos de alcance IPv4 e IPv6, aunque el túnel pareciera un enlace ordinario.
  • Filtrar alcance hacia IPv6 era una decisión de colocación: la ruta elegía qué router debía encapsular antes de transferir la responsabilidad a IPv4.
  • Una ruta, una salida de respaldo, una decapsulación o una recepción unidireccional eran pruebas acotadas, no demostraciones de autorización, simetría o servicio extremo a extremo.

La ruta debía encontrar la frontera correcta

RFC 2185, publicado en septiembre de 1997, describió una transición prolongada con infraestructuras IPv4 e IPv6 coexistentes. Definió la filtración de rutas como el anuncio de alcance de capa de red entre regiones de enrutamiento. Las rutas IPv4 procedían de protocolos IPv4 y las IPv6 de protocolos IPv6; aun si una implementación integraba ambas familias, el cálculo seguía siendo dual.

El registro del RFC Editor y la ficha de IETF Datatracker lo clasifican como Informativo, no como estándar de Internet. El texto propuso un diseño, pero no documentó cuántos operadores lo adoptaron, cómo rindió en producción ni si completó una migración.

Un túnel estático configurado manualmente simplificaba la vista IPv6: sus extremos formaban una adyacencia y el otro extremo parecía estar a un salto. El paquete exterior, sin embargo, recorría el camino que eligiera el enrutamiento IPv4. La adyacencia demostraba un acuerdo entre extremos; no el estado de cada router intermedio, los filtros, la capacidad ni el retorno.

RFC 1933 describió las responsabilidades mecánicas de la transición, como MTU, fragmentación y errores ICMP. RFC 2003 especificó IP dentro de IP y presupuso que el extremo de salida podía decapsular. Esos documentos explicaron el envoltorio. RFC 2185 se ocupó de la pregunta de control: qué ruta llevaba el paquete al punto donde empezaba ese envoltorio.

Anunciar alcance significaba nombrar al encapsulador

En el caso automático entre hosts, las direcciones IPv6 compatibles con IPv4 permitían extraer las dos direcciones exteriores y encapsular en el origen. Con un router predeterminado configurado, un host enviaba el paquete exterior a la dirección IPv4 de un router dual conectado al núcleo IPv6; allí se quitaba el encabezado y continuaba el enrutamiento nativo. Esa dirección no era solo una ubicación: asignaba el punto de transferencia entre familias.

La variante router-a-host hacía todavía más explícita la autoridad. El router dual tenía que inyectar en la región IPv6 el alcance correspondiente a los destinos compatibles con IPv4. La red IPv6 dirigía el paquete hacia el router que había hecho esa promesa. Solo después entraba en juego IPv4 para el tramo exterior.

La escala convertía la promesa en una decisión de coste. Un stub IPv4 pequeño podía representarse con un resumen. Una frontera grande podía introducir toda la tabla IPv4 en el enrutamiento IPv6, casi duplicando el estado, o seleccionar manualmente los destinos que se creía que contenían sistemas IPv6. Una opción pagaba con memoria y superficie de fallo; la otra, con juicio humano y riesgo de información caducada.

El respaldo tampoco equivalía al servicio original. El RFC describió rutas de host para los extremos preferidos y un prefijo de cobertura capaz de atraer el tráfico a otro router si desaparecía la ruta específica. Eso probaba que algún anunciante del prefijo amplio había recibido el paquete. No probaba política equivalente, estado del túnel, MTU, capacidad, filtros ni continuación IPv6.

Además, las dos direcciones podían utilizar formas de túnel diferentes. Un trayecto de ida exitoso no describía el regreso. La sección de seguridad solo advirtió que el túnel podía vulnerar cortafuegos de la infraestructura subyacente; no trató otros problemas. Que el enrutamiento entregara un paquete tampoco lo autenticaba.

Cada observación tiene un alcance limitado

Una entrada de tabla demuestra una selección del plano de control. Un prefijo filtrado demuestra que una región anunció una pretensión a otra. Una adyacencia virtual demuestra intercambio de control. La decapsulación demuestra que un paquete exterior llegó a una salida operativa. Una respuesta de aplicación agrega evidencia, pero únicamente para la dirección, el momento y la prueba observados.

Nada de ello prueba por sí solo la autorización del anuncio, la ausencia de bucles, la simetría, la capacidad sostenida, la entrega completa ni el fin de la transición.

El límite separa esta historia de sus vecinas. RFC 1955 propuso ENCAPS y desplazó otra abstracción hacia encabezados de dominio autónomo, DNS y routers de borde. RFC 4213 documentó después mecanismos básicos de transición y conservó la distinción: el túnel es un salto IPv6, pero su TTL y su camino IPv4 son independientes. RFC 2185 mostró quién debía unir esas capas.

La primacía del código en ejecución de Lu Heng aporta una lente atribuida: publicar o configurar no equivale a ejecutar. Su especificación inicial mínima favorece invariantes comunes estrechos y decisiones posteriores localizadas. Su tesis sobre el impuesto permanente de la doble pila interpreta el coste de operar superficies paralelas, pero no demuestra el despliegue de RFC 2185. Su ensayo sobre capas de realidad refuerza la disciplina: anuncio, ejecución y resultado pertenecen a niveles probatorios diferentes.

El valor histórico del memo no consiste en probar que la transición funcionó. Consiste en localizar el cambio de dueño de la promesa: IPv6 debía escoger el encapsulador; IPv4 debía alcanzar la salida; solo la observación extremo a extremo podía decir si ambos cumplieron.