Resumen

  • En RFC 5177 hay un resultado general y varios resultados por prefijo. El primero indica éxito cuando al menos un Mobile Network Prefix obtuvo reenvío; no resume correctamente a los demás.
  • Una actualización explícita también elimina todo prefijo anterior que ya no aparezca. El denominador correcto no es «un registro», sino el inventario completo antes y después del cambio.

Imagine cuatro subredes que se mueven detrás del mismo Mobile Router. La primera está autorizada y recibe estado de reenvío. La segunda no figura emparejada con la Home Address. La tercera está autorizada, pero el Home Agent no dispone de recursos para instalarla. La cuarta funcionaba antes, pero faltó en la actualización.

El resultado normativo puede ser una respuesta principal con código cero. Al mismo tiempo, la segunda recibe MOBNET_UNAUTHORIZED, la tercera MOBNET_FWDING_SETUP_FAILED y la cuarta desaparece de la tabla con su reenvío desactivado. «Éxito» describe una condición existencial: por lo menos uno.

La aritmética escondida en el estado verde

El modo explícito de NEMOv4 coloca cada prefijo en una extensión separada. El Home Agent consulta una Prefix Table para comprobar que la dirección de origen del Mobile Router está vinculada a ese prefijo. Después intenta crear el reenvío. La respuesta conserva esa granularidad mediante una extensión de reconocimiento por prefijo.

El código principal opera con otra regla. Si hubo reenvío para uno o más prefijos, es cero. Si no lo hubo para ninguno, pasa a HA_MOBNET_ERROR. Por tanto, el color del registro no dice cuántos miembros tenía el conjunto solicitado ni qué proporción sobrevivió.

Una operación con 1 de 1 y otra con 1 de 40 pueden verse idénticas en un cuadro que solo guarda el código general. Esa pérdida del denominador no es simplificación inocua: cambia el significado de la evidencia.

La autorización no se hereda entre subredes

La solicitud y sus extensiones se autentican según las reglas de Mobile IPv4. Sin embargo, el Home Agent debe autorizar a ese router para cada red antes de anclar su prefijo. La integridad del mensaje no demuestra titularidad sobre todas las direcciones nombradas.

El diseño perimetral es deliberado. Un prefijo puede ser rechazado sin convertir al resto en sospechoso; otro puede superar la autorización y fallar solo por capacidad. Conservar los códigos separados permite responder preguntas distintas: ¿quién podía anunciarlo?, ¿había recursos?, ¿se instaló realmente?

Una lista incompleta ejecuta una retirada

Al actualizar una asociación existente, RFC 5177 ordena comparar la tabla anterior con la lista incluida. Si un prefijo previo falta, se borra y se deshabilita el reenvío. La ausencia no significa «sin cambios».

Esto hace que el proceso que prepara la solicitud tenga poder de retirada. Si reúne datos desde varias fuentes, su consistencia importa tanto como la autenticación del paquete. Un mensaje perfectamente válido, creado a partir de una réplica atrasada, puede contraer el servicio de manera perfectamente válida.

Por eso el registro de auditoría necesita el conjunto anterior, el conjunto pretendido y el conjunto enviado. Sin esa triple comparación, ni siquiera el reconocimiento por prefijo explica si lo ausente fue una decisión o un fallo de inventario.

Del Home Agent a la experiencia hay más saltos

Un reconocimiento positivo significa que el Home Agent aceptó el prefijo y configuró el reenvío en su ámbito. Después quedan la propagación o agregación de alcance, la convergencia de rutas, el túnel bidireccional y la ruta de datos.

RFC 5177 separa además la movilidad del router de los cambios topológicos internos. Un protocolo dinámico puede transportar esos cambios a través del túnel. Si el mismo prefijo llega también por la solicitud Mobile IPv4, pueden aparecer FIB incoherentes; el documento aconseja modo implícito cuando el enrutamiento es la fuente.

En redes móviles anidadas tampoco hay una garantía final: el protocolo no detecta bucles físicos y cada nivel añade encapsulación, reduciendo la MTU útil. Un prefijo puede haber sido admitido correctamente y seguir sin entregar la aplicación.

RFC 6626 conserva los resultados por miembro

La actualización RFC 6626 permite pedir asignación colocando cero como prefijo. El largo solicitado puede ser una pista, no una obligación. El Home Agent puede devolver una asignación o MOBNET_UNASSIGNED, y una sola solicitud puede pedir varias.

De nuevo, una asignación positiva no convierte al lote en éxito completo. Cada prefijo concedido hereda la vida de la asociación; cada fallo necesita su código. Los límites de cantidad y tamaño también sirven para contener agotamiento de direcciones.

La conclusión operativa es simple, aunque exige más trabajo: nunca informar el registro sin informar su cardinalidad. El estado global es una puerta. El inventario por prefijo es el servicio que pasó —o no— por ella.

Fuentes