Resumen

  • RFC 5220 describió una red IPv6 “semiabierta” en la que la regla predeterminada del host podía escoger como origen una dirección cuyo prefijo no era alcanzable desde Internet.
  • La elección de la dirección y la del primer salto son decisiones distintas. El RFC documentó un desajuste posible, no una implantación concreta, una tasa de fallos ni el comportamiento de todos los hosts multiconectados.

Dos prefijos válidos, una respuesta inalcanzable

Publicado en julio de 2008, RFC 5220 es un documento informativo sobre la selección de direcciones IPv6 cuando un mismo enlace tiene varios prefijos. No añadió un formato de paquete. Reunió situaciones en las que las reglas predeterminadas de RFC 3484 para elegir origen y destino resultaban difíciles de operar, sobre todo en equipos que los administradores no podían configurar uno por uno.

Su ejemplo más revelador se llama “red semiabierta”. Un sitio pequeño está conectado a dos redes ascendentes: una ofrece acceso normal a Internet y la otra es una red cerrada, por ejemplo una VPN. El host tiene una dirección IPv6 válida de cada una. Un compañero dentro de la red cerrada puede usar su dirección interna; un servidor público no puede devolver tráfico a esa dirección por Internet.

El fallo aparece cuando el host inicia una conexión hacia un destino público. En el escenario de RFC 5220, la regla de coincidencia de prefijo más largo puede escoger como origen la dirección de la red cerrada. Sin embargo, la ruta predeterminada del sitio puede enviar el paquete por el proveedor de Internet. Ese proveedor puede descartar un prefijo que no asignó. Si el paquete sí sale, la respuesta del servidor público se dirige al prefijo cerrado y no encuentra un camino de vuelta por la red pública. Que la dirección sea válida no significa que la conversación pueda completarse.

El documento separa dos puntos de ruptura. El filtrado de entrada puede rechazar el paquete de salida porque el origen no corresponde al proveedor elegido. La ruta de retorno de una red semiabierta puede fallar incluso si el paquete logró salir. Ninguna de las dos cosas es simplemente un problema de DNS ni demuestra que la dirección del host estuviera mal formada.

La dirección no revelaba la política del proveedor

RFC 3484 ofrecía comparaciones predeterminadas entre direcciones candidatas. No le indicaba automáticamente al host qué proveedor transportaría el paquete ni si el prefijo de origen podría recibir la respuesta por ese trayecto. RFC 5220 trata estos casos como coordinación entre la decisión del host y la política de encaminamiento. En su ejemplo, ajustar la tabla de políticas del host podía evitar la selección incorrecta, pero alguien debía conocer la topología y mantener esa regla al día.

El documento distingue los casos que cabían en el marco de selección existente de los que quizá exigían más información u otro mecanismo. No afirma que todas las redes IPv6 con varios proveedores estuvieran rotas, ni cuantifica la frecuencia de los ejemplos en producción. Un diagrama identifica un modo de fallo que merece análisis; no es un informe de incidente.

Los documentos posteriores hicieron más explícita parte de esa frontera. RFC 6724 reemplazó a RFC 3484. En 2016, RFC 8028, de la vía de estándares, describió cómo elegir el primer router en una red con varios prefijos y cómo relacionar el prefijo anunciado con la dirección origen y el router de salida. Permite seguir la evolución técnica, pero no demuestra cuán frecuentes fueron los casos de 2008 ni elimina la necesidad de probar la ruta de retorno de cada red real.

Una advertencia normativa no mide el tráfico

La aportación histórica de RFC 5220 es separar piezas que a menudo se confunden: dirección de origen, siguiente salto, filtrado del proveedor y alcanzabilidad de vuelta están relacionados, pero ninguno acredita los otros. El texto analiza configuraciones plausibles. No aporta un inventario de sistemas operativos, una captura de paquetes, un incidente identificado ni una medición antes y después. Para saber cuántos hosts escogieron mal, o qué mejoró el trabajo posterior, hacen falta pruebas de implementaciones y redes reales.

Fuentes

  1. RFC 5220 — Problema de selección predeterminada de direcciones en entornos con varios prefijos
  2. RFC 3484 — Selección predeterminada de direcciones IPv6
  3. RFC 6724 — Selección predeterminada de direcciones IPv6
  4. RFC 8028 — Selección del primer router por hosts en una red con varios prefijos
  5. RFC 2827 — Filtrado de tráfico entrante
  6. RFC 4193 — Direcciones IPv6 locales únicas
  7. Ficha del editor RFC para RFC 5220
  8. Ficha del editor RFC para RFC 8028