Resumen

  • En el modo predictivo, el FBU, el intercambio HI/HAck y el túnel pueden completarse antes de que el nodo abandone el router anterior; son comprobantes de preparación, no de presencia en el nuevo enlace.
  • La conexión de enlace, DAD o la asignación de una NCoA alternativa, el UNA, la liberación del búfer, el binding ordinario, la recepción y el resultado de la aplicación requieren pruebas propias.

Ganar tiempo exige conservar la diferencia temporal

FMIPv6 intenta evitar que toda la preparación IP empiece después de la mudanza. El móvil puede descubrir con antelación el router asociado a un punto de acceso, formar una posible nueva care-of address y pedir que el tráfico sea desviado. Mientras el dispositivo continúa en el enlace viejo, el camino siguiente ya puede recibir paquetes.

Esa inversión del orden es deliberada. Sin embargo, un sistema de gestión suele convertir el primer acuse verde en una conclusión total: “handover completado”. RFC 5268 no lo permite. Su optimización no incluye el tiempo de cambio de la capa de enlace y tampoco define el disparador radio que decidió predecir el movimiento.

RFC 5568 volvió obsoleto a RFC 5268 y es la referencia actual. La arquitectura de evidencia, no obstante, conserva la misma pregunta: ¿qué se preparó y qué acontecimiento posterior demostró que la predicción se volvió realidad?

Resolver un AP no sitúa al móvil allí

RtSolPr permite que el móvil consulte al router anterior por uno o varios AP-ID. PrRtAdv devuelve AR-Info: dirección de enlace del router candidato, dirección IP y prefijo utilizable en la interfaz de destino. Con ello se puede construir una NCoA prospectiva.

El dato significa “éste es el lugar donde podría prepararse el próximo salto”. No significa “el móvil está aquí”. La elección inicial depende de señales de enlace fuera de la especificación. Una predicción puede quedar abandonada por cobertura, política, movimiento inverso o asociación fallida.

Cada intento necesita una generación propia. Si dos movimientos apuntan al mismo AP, guardar sólo el destino aparente permite que una respuesta antigua autorice una transición nueva. El AP-ID, el AR-Info y la NCoA han de quedar vinculados a la observación que los produjo.

FBack puede llegar antes que el propio móvil

En modo predictivo, el nodo envía FBU desde el enlace anterior. Solicita ligar PCoA con la NCoA prevista y redirigir el tráfico. La opción FMIPv6 Binding Authorization Data aporta al router anterior la autorización relativa a la PCoA.

Luego, PAR y NAR intercambian HI y HAck. El NAR acepta, sustituye o rechaza la dirección propuesta. Si FBack vuelve antes del cambio, confirma que el PAR procesó la preparación y que el túnel está en marcha. Su punto de observación sigue siendo el enlace viejo.

El modo reactivo deja visible el corte. Si el nodo llega al nuevo enlace antes de completar el flujo predictivo, o abandonó el viejo sin recibir FBack, envía UNA después del attachment y envía o repite FBU. La ausencia de FBack significa que el móvil no sabe si su primera solicitud fue procesada.

Tampoco HI/HAck localiza al dispositivo. Es una disposición entre routers, protegida por una asociación de seguridad creada fuera de la especificación. Autoriza infraestructura; no detecta presencia física.

La dirección prevista todavía puede no ser la dirección válida

Una NCoA derivada del prefijo empieza como propuesta. El NAR puede aplicar Duplicate Address Detection, aceptar esa dirección o devolver otra en HAck/FBack. Incluso después de la llegada, NAACK puede revelar un conflicto y obligar a usar una alternativa y emitir un nuevo FBU.

La probabilidad pequeña de colisión no equivale a certeza. RFC 5268 sólo contempla omitir DAD bajo una política explícita, por ejemplo cuando la administración de direcciones mantiene el riesgo en un nivel despreciable. La disciplina de RFC 4862 sigue marcando la frontera.

Por ello, “NCoA” debe ser una genealogía: valor propuesto localmente, resultado DAD o motivo para omitirlo, valor asignado por el router, anuncio posterior al attachment y dirección que terminó participando en Mobile IPv6 ordinario. Sin esa historia, una dirección ya descartada puede conservar autoridad accidental.

UNA habilita el forwarding; no certifica la entrega

RFC 5268 advierte que establecer el túnel no basta para asegurar la recepción tras el attachment si el NAR no puede detectar la presencia del móvil.

Una vez conectado el enlace, el nodo envía un Unsolicited Neighbor Advertisement con Override desactivado. El NAR puede eliminar una entrada proxy o llevar una entrada incompleta a STALE y, desde ese momento, transferir paquetes del túnel y liberar los que estaban en el búfer.

UNA es una prueba importante y concreta: el móvil habló desde el nuevo enlace y provocó un cambio de vecindad. Aun así, no demuestra que todos los paquetes fueron retenidos, recibidos por el host o consumidos por la aplicación.

La evidencia debe poder recorrerse hacia atrás: attachment, UNA, mutación del neighbor cache, apertura del búfer, paquetes emitidos, recepción observada y señal de aplicación. Si sólo queda el estado “completo”, la organización no puede determinar en qué frontera terminó la realidad.

El búfer puede trasladar la pérdida en vez de eliminarla

Los paquetes que llegan al NAR antes que el móvil se pierden si no se almacenan. En un traspaso reactivo también puede haber pérdida en el PAR mientras espera el FBU. El búfer reduce una ventana, pero crea otra decisión: cuánto admitir y cómo vaciarlo.

Una descarga brusca puede sobrecargar router, enlace o terminal, causando congestión, jitter y pérdidas nuevas. RFC 5268 define un comportamiento por defecto guiado por la velocidad de llegada original y limita la ráfaga inicial a cinco paquetes consecutivos antes de regular el resto.

“Búfer vaciado” sólo afirma que el router dejó de retener esos datos. Capacidad, overflow, rango conservado, disparador, ritmo de salida, transmisión y recepción son mediciones independientes. Ninguna debe heredarse de la anterior.

El formato antiguo también es un límite de generación

RFC 5568 reemplazó a RFC 5268 e introdujo una diferencia operativa: HI y HAck dejaron de ser los mensajes ICMPv6 del documento antiguo y pasaron a Mobility Header. Una implementación actual no debe transmitir el formato de RFC 5268, aunque pueda interpretar mensajes viejos recibidos.

Por eso, una captura que sólo dice “HI” no identifica el protocolo ejecutado. Debe conservar formato, generación y dirección. RFC 5268 sigue siendo evidencia histórica del límite preparación-llegada, no permiso para desplegar su codificación superada.

El trabajo normal de Mobile IPv6 continúa después. El atajo predictivo no sustituye Binding Update, Return Routability ni la autoridad de binding que corresponda según RFC 6275.

El código real es una secuencia, no la palabra “sin interrupción”

Running-Code Primacy, de Lu Heng, obliga a describir lo que de verdad se ejecuta: señal candidata, RtSolPr/PrRtAdv, NCoA prevista, autorización FBU, disposición de routers, túnel y búfer, enlace real, UNA, confirmación de dirección, liberación, binding, recepción y aplicación.

La disciplina de capas de realidad evita sustituciones: predecir no es preparar; preparar no es llegar; llegar no es demostrar unicidad; habilitar forwarding no es entregar; entregar no es continuidad.

El traspaso rápido obtiene su valor dejando que una capa se adelante. La abstracción sólo merece confianza si conserva esa distancia y si cada conclusión vuelve a una generación, un modo, una genealogía de dirección y la última frontera efectivamente probada.

Fuentes