Resumen

  • RFC 3964 distinguió la coherencia entre la fuente IPv4 exterior y el prefijo IPv6 interior de la identidad, la autorización y la entrega; una coincidencia era una prueba local, no una atribución.
  • Como la desencapsulación retiraba la cabecera exterior, la unión entre ambas capas, la instancia real del relé y cada decisión de admisión debían registrarse antes de la transformación.

Pensemos en el incidente desde el final. Un servidor IPv6 conserva una dirección fuente. El operador de un relé recibe una queja. Entre ambos existe un salto que ya no aparece en el paquete. Para RFC 3964, ese vacío no era una metáfora: era el resultado ordinario de desencapsular.

RFC 3056 había definido 6to4 en 2001. Un sitio con una dirección IPv4 global construía 2002:V4ADDR::/48. Si el destino también era 6to4, el router extraía V4ADDR y enviaba el paquete IPv6 dentro de IPv4, usando el protocolo 41. Si el otro extremo pertenecía al IPv6 nativo, un relé traducía el trayecto entre los dos dominios de encaminamiento.

El diseño comprimía configuración en una dirección. También comprimía responsabilidades distintas en un solo paquete. La cabecera exterior describía el túnel IPv4 observado; la interior declaraba el flujo IPv6 que debía continuar. Que una máquina supiera quitar la primera no convertía la segunda en una afirmación autenticada.

La escena anterior a la transformación

El apéndice de RFC 3964 presenta cuatro campos visibles antes de desencapsular: fuentes y destinos IPv4 e IPv6. Después quedan sólo los dos campos interiores. El documento advierte que las direcciones IPv4, tratadas como si fueran información de enlace, se pierden para el procesamiento posterior.

No eran una identidad perfecta. La fuente IPv4 podía estar falsificada; podía pertenecer a un relé y no al originador; una dirección anycast podía representar muchas instancias. Pero respondía a una pregunta que la dirección interior no podía contestar por sí sola: ¿qué extremo IPv4 entregó esta envoltura en este límite y en este momento? Si el dato se descartaba, la respuesta dejaba de ser incompleta para pasar a ser irrecuperable.

RFC 3964 exigía contrastar ambas capas cuando la fuente interior era 6to4. La porción IPv4 incorporada en 2002:V4ADDR::/48 debía coincidir con la fuente exterior. El receptor también debía rechazar valores que no fueran destinos globales adecuados: multicast, broadcast, bucle local, redes privadas y otros espacios especiales. Las restricciones se apoyaban en requisitos de router como RFC 1812 y hoy pueden contrastarse con el registro de direcciones IPv4 de propósito especial de IANA.

Una coincidencia elevaba la calidad de la evidencia, pero sólo hasta cierto punto. Demostraba que dos campos concordaban bajo una regla concreta. No demostraba quién controlaba el equipo, si la asignación seguía vigente, si el relé estaba autorizado ni si una persona había querido la acción.

El filtrado de fuente podía añadir otro control. RFC 2827 / BCP 38 buscó impedir que direcciones falsas abandonaran la red de origen; RFC 3704 / BCP 84 trató los casos multihomed. Aun así, “pasó el filtro” significa “fue plausible para este borde y esta época”, no “se identificó al actor”. RFC 3964 incluso observó que la dependencia de un filtrado IPv4 generalizado resultaba poco realista.

Cuando no había nada que comparar

En el sentido desde IPv6 nativo hacia un sitio 6to4, la fuente interior no empieza por 2002:. La fuente IPv4 exterior suele ser la del relé, pero no existe un valor incorporado que deba coincidir. El router 6to4, decía RFC 3964, no podía distinguir fácilmente un relé legítimo de un tercero que enviara tráfico con su apariencia.

Es una frontera parecida a la que RFC 3756 estudió para Neighbor Discovery: poder hablar desde el enlace no equivale a tener autoridad para desempeñar el papel de router. 6to4 hizo que el “enlace” conceptual abarcara nodos IPv4 remotos. La recepción del sobre sólo probaba recepción.

Por eso el RFC repartía las defensas: cotejo de prefijo cuando procedía, rechazo de direcciones especiales, prohibición de reenviar 6to4 hacia 6to4 a través del relé, descarte de tráfico destinado a prefijos ajenos y limitación de rutas. Un único indicador válido habría ocultado qué prueba se hizo y cuál no era aplicable.

192.88.99.1 encontraba un relé, no nombraba al responsable

RFC 3068 introdujo la dirección anycast 192.88.99.1. El encaminamiento IPv4 elegía un relé cercano, y un relé averiado podía retirar el anuncio. La idea eliminaba configuración manual, pero el propio RFC señaló que resultaba difícil saber qué relé específico había recibido el tráfico.

La ruta era una señal de selección, no un recibo de servicio. No acreditaba que la instancia escogida quisiera transportar el paquete, tuviera salida IPv6, aplicara los controles, dispusiera de capacidad o coincidiera con el relé del regreso. El anycast resolvía “encuentra alguno”; la investigación necesitaba “identifica éste”.

La diferencia se volvió operativa en RFC 6343. El documento describió agujeros negros, relés no administrados, anuncios que atraían tráfico sin prestar servicio y trayectos de ida y vuelta por operadores diferentes. Los filtros con estado podían aceptar una dirección exterior y rechazar otra. La disponibilidad dependía de una cadena que ningún participante observaba completa.

En 2015, RFC 7526 deprecó formalmente el 6to4 anycast y 192.88.99.1. No deprecó el mecanismo básico de RFC 3056 ni 2002::/16. La diferencia impide afirmar que una decisión normativa borró de inmediato todos los túneles. El estado del estándar y la existencia de tráfico son pruebas distintas.

El relé podía cargar con una culpa que no era suya

RFC 3964 separó varias familias: denegación de servicio, reflexión, blanqueo de paquetes, broadcast IPv4 local, robo de servicio y abuso administrativo. Una cabecera exterior con la dirección de un relé podía hacer que éste pareciera el originador. Una fuente IPv6 falsificada podía hacer que la respuesta dañara a un tercero. Tras desencapsular, los registros de destino podían conservar sólo la reclamación interior.

RFC 6169 generalizó después el límite de los túneles: los controles aplicados al portador no inspeccionan necesariamente la carga interna, y sólo los extremos pueden reproducir el filtrado que el paquete interior evitó. La seguridad no viaja automáticamente con el encapsulado.

Para reconstruir un hecho se necesitan recibos sucesivos: ruta IPv4 elegida; interfaz e instancia que recibieron protocolo 41; cuatro direcciones observadas juntas; resultados individuales de cada regla; evento de desencapsulación; decisión de reenvío IPv6; recepción remota; efecto de aplicación; y evidencia aparte de identidad y autorización. Saltar de la coincidencia de direcciones al responsable convierte una comprobación técnica en una conclusión que no sostiene.

Fuentes y límites de la narración

La lectura se apoya en el texto de RFC 3964, su ficha editorial y su registro de erratas. Dos erratas técnicas verificadas corrigen una dirección de destino en un ejemplo y el prefijo anycast mal escrito; no documentan una explotación. Los antecedentes son RFC 3056 y 3068; los controles de origen, RFC 2827 y 3704; la experiencia y retirada, RFC 6343 y 7526; y el contexto de túneles, routers y confianza vecina, RFC 6169, 1812 y 3756.

Estas fuentes no prueban una implantación concreta, una víctima, una tasa de ataques, una conducta de proveedor ni la aplicación universal de BCP 38/84.