Resumen

  • HMIPv6 mantuvo estable una Regional Care-of Address mientras un Mobility Anchor Point actualizaba la dirección local cambiante.
  • Preferencia, distancia y tiempo de validez permiten escoger un MAP, pero no demuestran capacidad, ruta de túnel, MTU ni entrega a la aplicación.

La promesa todavía no había caducado

Supongamos que el móvil conserva una opción MAP con tiempo de validez positivo. El valor de preferencia sigue siendo alto. Ningún Router Advertisement ha comunicado una retirada. El registro RCoA-LCoA recibió un Binding Acknowledgement. Desde la consola, la sesión parece estar dentro de contrato.

Sin embargo, los paquetes no llegan a la dirección local actual.

La contradicción sólo existe si se pide a cada señal que afirme más de lo que afirma. RFC 5380 utiliza la preferencia para expresar elección de operador y la distancia como dato de selección. La vigencia establece durante cuánto tiempo puede considerarse válida la opción. El estándar no define esos campos como una prueba continua de capacidad, pérdida, latencia, estado del caché o alcance de la LCoA.

Un MAP con vigencia cero sí produce una consecuencia inequívoca: no debe ser seleccionado, sus bindings pueden considerarse perdidos y el móvil debe buscar otro. La ausencia de ese cero no es el inverso lógico de la orden. «No retirado» no significa «entregando».

La estabilidad era una obra local

La idea central de HMIPv6 es reducir señalización distante. El móvil obtiene dos direcciones temporales. La RCoA pertenece al enlace lógico del MAP y se presenta al home agent o a los correspondent nodes. La LCoA pertenece al enlace de acceso actual. Mientras el móvil se mueve dentro del dominio del mismo MAP, cambia la LCoA y conserva la RCoA.

Para los interlocutores remotos, el móvil parece inmóvil. Para el MAP, todo ha cambiado: debe aceptar un nuevo binding, reemplazar la ubicación de destino y encaminar el túnel hacia ella. La continuidad no fue regalada por la dirección estable. Fue fabricada por una tabla de correspondencia y por el código que la ejecuta.

La arquitectura crea así una deuda de evidencia. Cuanto menos movimiento observan los extremos remotos, más importante es que la operación local conserve la secuencia de binding, su duración, la identidad del MAP, la LCoA vigente y la primera entrega verificada después de cada cambio.

Aceptar el binding no completa la ruta

El procedimiento de registro tiene una finalidad concreta. El móvil envía una Binding Update local. Si el MAP la acepta, guarda la relación RCoA-LCoA y devuelve un Binding Acknowledgement con los elementos exigidos por el protocolo. El móvil debería esperar esa respuesta antes de registrar la RCoA fuera del dominio.

Después empieza otro conjunto de obligaciones. El MAP debe interceptar tráfico dirigido a la RCoA, consultar el binding correcto, encapsular y enrutar hacia la LCoA. El móvil debe recibir y desencapsular. El tráfico saliente también cruza el túnel. La seguridad debe estar activa y el paquete debe caber en el tamaño útil del camino.

Por eso conviene separar cuatro estados que las herramientas suelen comprimir en uno: actualización enviada, actualización aceptada, primer paquete entregado y primera transacción útil. Reintentar el primer estado no arregla necesariamente el tercero.

El tiempo exterior depende del tiempo interior

RFC 5380 impone una regla especialmente valiosa: la duración del binding que el móvil registra con el home agent o los correspondent nodes no puede superar la duración del binding con el MAP. La dependencia está escrita en el tiempo.

Si el sistema exterior promete una RCoA durante más tiempo que el MAP conserva la relación con la LCoA, crea una dirección válida que nadie puede realizar. La regla evita esa promesa huérfana en el protocolo. Los sistemas de gestión deberían conservar la misma disciplina al renovar, almacenar en caché o mostrar el estado.

No basta con que cada componente tenga una fecha de expiración válida. El orden entre fechas es parte de la corrección.

Cambiar de dominio abre una ventana de copropiedad

Cuando cambia el MAP, también cambia la RCoA. El móvil puede avisar al MAP anterior para que reenvíe los paquetes en vuelo a la nueva localización. El administrador puede limitar el reenvío fuera del dominio, aunque la RFC recomienda permitir ciertos dominios vecinos bajo condiciones controladas.

Durante esa ventana, no existe un único objeto llamado «la ruta». El MAP antiguo conserva estado transitorio; el nuevo acepta la ubicación actual; el home agent y los interlocutores actualizan sus bindings en momentos diferentes. Las métricas deben mostrar quién recibió cada paquete y cuándo terminó la responsabilidad anterior.

Una retirada prematura pierde tráfico. Un reenvío demasiado largo mantiene una dependencia vieja y una superficie de fallo. El cierre correcto exige evidencia de que la ruta nueva funciona, no sólo un temporizador agotado.

El túnel cambia el tamaño del problema

La encapsulación de ida y vuelta entre móvil y MAP reduce el MTU disponible. Si además participa un home agent, puede haber doble encapsulación. RFC 5380 obliga al móvil a considerar esa sobrecarga al calcular el tamaño que ofrece a las capas superiores.

Esto permite un fallo muy limpio desde el punto de vista del control: los mensajes breves de movilidad pasan; los datos grandes no. Un sistema que sondea únicamente el Binding Acknowledgement puede declarar continuidad mientras el servicio pierde paquetes representativos. Deben probarse tamaños reales y observarse los mensajes de control de MTU, sin atribuir automáticamente toda pérdida a la movilidad.

Una relación autenticada sigue teniendo límites

La relación entre móvil y MAP necesita autenticación mutua, integridad y protección contra repetición. El operador también puede mantener una lista de prefijos locales válidos y rechazar una LCoA ajena al dominio. Son controles de autoridad importantes.

No convierten al MAP en testigo de la aplicación. Autenticar al móvil no mide el túnel. Autorizar el prefijo no demuestra que el radioenlace transporte datos. Proteger la actualización contra repetición no garantiza que el caché posterior conserve el estado esperado.

La seguridad hace fiable una afirmación estrecha. La arquitectura falla cuando esa fiabilidad se usa para ensancharla.

Varias anclas no eliminan el anclaje

RFC 7429 situó HMIPv6 dentro de una transición hacia una gestión más distribuida. Un MAP cercano reduce viajes de señalización a una ancla lejana. A la vez, aparecen problemas de descubrimiento, selección, reasignación y transferencia de contexto.

RFC 5380 permite registrar más de un MAP y usar distintas RCoA con grupos diferentes de interlocutores. También impide encadenar una RCoA de un MAP como care-of address de otro, porque la encapsulación múltiple degradaría el sistema. Tener varias opciones es capacidad; no es prueba de que una sesión conozca siempre cuál realiza su dirección.

La pregunta operativa no es cuántas anclas existen. Es si cada dirección activa conserva una asociación auditable con su ancla y su ubicación presentes.

Una dirección estable no es un veredicto

La disciplina de Heng Lu sobre el código en funcionamiento ayuda a formular el límite. La RCoA es un registro visible. El resultado depende de la entrada ejecutada por el MAP, del túnel, de la seguridad, del MTU y del procesamiento en el móvil. La soberanía sobre el nombre no sustituye la capacidad práctica de transportar el paquete.

El operador necesita recibos separados de descubrimiento, selección, adquisición de direcciones, registro, persistencia del caché, forwarding, viabilidad del camino, recepción y servicio. El primer recibo que falta define el punto de investigación.

El MAP seguía vigente. El camino necesitaba una prueba distinta.

Fuentes