Resumen

  • RFC 5142 asigna el tipo 12 del Mobility Header al mensaje con el que un agente local pide a un nodo móvil que deje de usarlo y adquiera otro.
  • El protocolo no decide cuándo ni a quién mover: la política de mantenimiento, carga o balanceo pertenece al sistema local.
  • El mensaje puede ofrecer alternativas IPv6 ordenadas por preferencia o una lista vacía que obliga al descubrimiento.
  • La protección IPsec autentica el mensaje, no la capacidad, la admisión ni el estado de encaminamiento del destino.
  • Si envía el mensaje el agente actual, el Binding Update que elimina la asociación antigua funciona como acuse de recibo.
  • Eliminar la asociación de origen demuestra una salida de control, pero no la entrada operativa en el destino.
  • El descubrimiento, la dirección de origen, las asociaciones de seguridad, el registro nuevo, el túnel y los paquetes requieren pruebas propias.
  • La falta de respuesta no revela el estado del nodo; el agente antiguo debe mantener el servicio hasta que venza la asociación.
  • El envío necesita realimentación de recursos del agente nuevo o una tasa prudente; el máximo predeterminado es un mensaje por segundo.
  • Una alternativa situada en otro prefijo puede cambiar la dirección de origen y cortar conexiones aunque el registro nuevo sea válido.
  • La aceptación de un Binding Update sigue siendo una evidencia del plano de control, no una garantía extremo a extremo.
  • La dirección debe gobernar el relevo por etapas y conservar capacidad de reversión hasta observar tráfico útil.

La dirección estable forma parte del servicio

Un panel puede mostrar una secuencia impecable: mensaje de cambio validado, agente alternativo elegido, Binding Update aceptado. Aun así, una sesión iniciada antes de la maniobra puede desaparecer. Si la alternativa pertenece a otro prefijo de origen, el nodo quizá tenga que adquirir otra Home Address. Para el protocolo de transporte, ese cambio no es un detalle administrativo: altera uno de los extremos de la conversación.

RFC 5142 recomienda evitar el mecanismo cuando sea necesario cambiar la dirección de origen y favorece agentes que comparten prefijos en los casos de balanceo. La cautela introduce una definición más rigurosa de éxito. No basta con demostrar que el nodo está registrado “en algún lugar”. Hay que demostrar que conserva la identidad de red exigida por sus conexiones o reconocer de antemano qué continuidad se sacrifica.

El estándar, por tanto, no describe un traslado atómico. Coordina una salida y orienta una búsqueda. Entre ambas queda la parte que una operación responsable debe instrumentar.

El mensaje propone; la infraestructura decide

Home Agent Switch usa el tipo 12 del Mobility Header. Un agente autorizado lo envía para indicar al nodo móvil que deje de usar el agente vigente y adquiera otro. Las razones citadas incluyen mantenimiento, balanceo de carga, separación funcional y renumeración. El criterio que activa el cambio está fuera del alcance del documento.

Esa separación protege una arquitectura sensata. El formato común transporta una instrucción mínima; el operador conserva la decisión sobre presión real, prioridad de usuarios, ventanas de mantenimiento y riesgo aceptable. El receptor tampoco recibe una política completa, sino información para dar el siguiente paso.

El mensaje puede contener una lista de direcciones IPv6 alternativas. La preferencia definida para Mobile IPv6 ordena las opciones y las de igual preferencia se aleatorizan. El nodo prueba la siguiente si la primera no puede prestarle servicio. Si la lista no incluye ninguna dirección, debe ejecutar un mecanismo de descubrimiento.

Una dirección en esa lista no es una plaza reservada. Tampoco afirma que las credenciales estén listas, que el agente admita al nodo, que el prefijo sea compatible o que la ruta responda. La lista reduce el espacio de búsqueda; no elimina la necesidad de verificar la realidad.

La seguridad delimita al emisor, no el resultado

La relación IPsec entre agente y nodo protege el mensaje. Se exige integridad mediante ESP, y puede usarse confidencialidad para ocultar las alternativas. Incluso un agente que no sea el actual puede enviar el cambio si posee la asociación de seguridad apropiada; normalmente se ofrecerá a sí mismo como destino.

El valor de esa protección es concreto: origen criptográfico, integridad y resistencia frente a repetición dentro del marco configurado. No mide la cola de IKE del destino, su memoria para asociaciones, la instalación del túnel ni la latencia del nuevo camino. Un mensaje auténtico puede contener una propuesta que ya quedó obsoleta por la carga.

Conviene registrar cuatro atributos por separado: identidad del emisor, autoridad configurada para ordenar el cambio, evidencia que justificó la selección y vigencia de la capacidad del receptor. Un único sello “seguro” no responde a esas cuatro preguntas.

El acuse que termina una relación

El detalle más fácil de malinterpretar aparece en el acuse. Cuando el agente local vigente envía el mensaje, el nodo deja de usarlo y remite un Binding Update para eliminar la asociación antigua. El RFC establece que esa actualización actúa como acuse del Home Agent Switch. El emisor puede detener las retransmisiones.

En el caso distinto de un mensaje enviado por un agente que aún no es el vigente, el Binding Update que intenta crear la asociación con ese emisor sirve de acuse. Uno confirma una baja en el lado anterior; el otro confirma una solicitud de alta en el lado propuesto. Ambos son progreso, pero no el mismo progreso.

El primer evento puede ocurrir sin que exista ninguna asociación nueva. El segundo puede recibir un Binding Acknowledgement de rechazo. Y una aceptación sólo dice que el estado de control fue admitido; todavía faltan ruta, encapsulación, paso de paquetes y resultado de la sesión.

Un registro de operaciones debe guardar los verbos, no un adjetivo: se ordenó el cambio, se recibió, se eliminó la asociación antigua, se descubrió una alternativa, se inició la seguridad, se solicitó la nueva asociación, se aceptó, se instaló el túnel, se observó el primer paquete, se comprobó la continuidad. La palabra “completado” debe reservarse para el último nivel que realmente se observó.

El protocolo prohíbe convertir el silencio en certeza

El agente retransmite mientras espera el Binding Update correspondiente. El intervalo parte de cinco segundos, crece de forma exponencial y llega a un máximo de veinte. Puede continuar después con una frecuencia menor.

Si acaba el tiempo máximo y la asociación antigua sigue viva, el agente no debería inferir el estado del nodo. Debe seguir prestando servicio hasta que venza la vida de la asociación. Esta instrucción impide una práctica peligrosa: usar la ausencia de respuesta como permiso para retirar antes el único camino conocido.

El silencio no separa pérdida de red, caída del nodo, fallo de descubrimiento, problema de credenciales, rechazo del destino o demora. Tampoco la caducidad posterior prueba el éxito; únicamente prueba que terminó el estado antiguo. La supervisión tiene que conservar la categoría desconocido en lugar de ocultarla bajo migrado o fallido.

Descubrir no es registrarse; registrarse no es transportar

Los documentos de arranque de Mobile IPv6 muestran cuánto trabajo queda fuera del mensaje. El nodo necesita localizar un agente, disponer de una Home Address y establecer la autorización y las asociaciones IPsec necesarias. RFC 5026 organiza esos componentes. RFC 6610 y RFC 6611 aportan mecanismos para descubrir o aprovisionar información. RFC 4640 explica el problema de arranque que los une.

Después viene el nuevo Binding Update. Un Binding Acknowledgement informa de aceptación o rechazo. Sólo más tarde puede existir el estado de túnel y encaminamiento. La prueba de paquetes llega después, y la prueba de continuidad de la aplicación después de ella.

La cadena completa debería conservar: la causa y el instante del cambio; los bytes protegidos del mensaje; la lista y sus preferencias; la verificación del nodo; el tipo exacto de acuse; los intentos de cada alternativa; el resultado de IKE/IPsec; el estado del nuevo Binding Update; la configuración del túnel; el tráfico; y el efecto visible para la aplicación. Perder un eslabón no invalida todos los anteriores, pero impide hacer una afirmación posterior.

El cuello de botella está en la llegada

El agente de origen puede enviar instrucciones con poco coste mientras el destino afronta criptografía, validación, creación de asociaciones y estado de túnel. Para evitar que el propio balanceo cause una sobrecarga, RFC 5142 exige una realimentación entre los recursos del agente nuevo y los mensajes adicionales, o una tasa máxima muy inferior a la capacidad de nuevos registros. El valor predeterminado es un mensaje por segundo.

Esta tasa debe entenderse como límite de seguridad, no como objetivo. Si aumentan los rechazos, las demoras IKE o el tiempo hasta el primer paquete, la salida debe frenarse. La métrica rectora es cuánto puede absorber y demostrar el destino, no cuánto puede emitir el origen.

También importa la calidad del camino. La nueva ruta puede introducir retraso, pérdida o reordenamiento perjudicial para los transportes. Por eso el primer paquete no cierra necesariamente la evaluación: el operador debe comparar el comportamiento de la sesión y el objetivo que motivó la maniobra.

Fuentes

  1. RFC 5142 en HTML
  2. RFC 5142 en texto
  3. Registro del RFC Editor
  4. IETF Datatracker
  5. Historial del documento
  6. Consulta de erratas de RFC 5142
  7. Parámetros de movilidad de IANA
  8. RFC 3775: movilidad en IPv6
  9. RFC 6275: movilidad en IPv6
  10. RFC 4301: arquitectura de seguridad IP
  11. RFC 4303: Encapsulating Security Payload
  12. RFC 4877: Mobile IPv6 con IKEv2 e IPsec
  13. RFC 5026: arranque de Mobile IPv6
  14. RFC 6611: arranque integrado de Mobile IPv6
  15. RFC 6610: opciones DHCP para descubrir información local
  16. RFC 4640: problema de arranque de Mobile IPv6
  17. RFC 4192: renumeración de redes IPv6
  18. Especificación inicial mínima, decisión futura localizada y adopción voluntaria
  19. Capas de realidad, poder simbólico y claridad
  20. Primacía del código en ejecución