Resumen

  • El bit S de RFC 3344 permitía solicitar que el agente de origen aceptara una dirección care-of nueva sin eliminar las vinculaciones de movilidad anteriores.
  • Si el agente admitía vinculaciones simultáneas, replicaba cada datagrama interceptado hacia todas las direcciones activas; el último registro aceptado no demostraba que quedara un solo camino.

Una base de movilidad puede parecer un registro que se sobrescribe: una dirección de origen estable y una dirección temporal que cambia. Pero RFC 3344 admitió otra forma. La misma identidad de red podía tener varias filas activas, cada una con su propio vencimiento, y el comportamiento de reenvío era enviar por todas, no elegir una.

La petición estaba codificada en el bit S del mensaje Registration Request. El nodo móvil lo activaba para pedir que el agente de origen conservara sus vinculaciones previas. Si no lo hacía, o si el agente no ofrecía esa capacidad, el nuevo estado sustituía al anterior.

La dirección care-of era un extremo, no una ubicación certificada

Mobile IPv4 mantenía la dirección de origen aunque el nodo saliera de su red. La dirección care-of indicaba dónde terminaba el túnel: podía ser la dirección de un agente extranjero que desencapsulaba o una dirección co-localizada obtenida por el propio nodo.

El dato servía para reenviar. No probaba dónde estaba físicamente una persona o un equipo, ni que el enlace siguiera operativo. La autenticación de la solicitud daba autoridad al cambio de estado, pero no certificaba decapsulación, recepción por la aplicación o continuidad de la ruta.

RFC 3344 mencionó el caso de un nodo dentro del alcance de más de un agente extranjero. Con vinculaciones simultáneas, el agente de origen guardaba varios extremos de túnel. Al interceptar un datagrama destinado a la dirección de origen, generaba una copia para cada care-of activa. El protocolo advertía que el nodo recibiría copias múltiples y recordaba que IP permite duplicación.

Dos verdes no significaban lo mismo

El código 0 de la respuesta significaba registro aceptado. El código 1 también era éxito, pero añadía que el agente no admitía vinculaciones simultáneas. El registro de números Mobile IPv4 de IANA mantiene ambos códigos en la sección de resultados satisfactorios.

Así, una solicitud con S seguida de código 0 podía dejar dos o más filas vivas. La misma solicitud seguida de código 1 aceptaba la nueva dirección sin confirmar la conservación de las anteriores. El código 135 era distinto: rechazo por exceso de vinculaciones simultáneas.

Un panel que reduzca 0 y 1 a “correcto” elimina justo la señal necesaria para interpretar el tráfico. Si después aparecen dos copias, no basta para decir que hubo replay. Si sólo aparece una, tampoco demuestra por sí sola que la vinculación antigua fue borrada. Hacen falta la solicitud autenticada, el código, la lista del agente y los vencimientos.

Cada fila tenía su propia salida

La duración cero podía tener dos alcances. Con la dirección de origen pedía eliminar todas las vinculaciones y terminar el servicio. Con una care-of concreta eliminaba sólo esa entrada; las demás seguían activas. Una duración distinta de cero agregaba la care-of solicitada y, únicamente con S admitido, conservaba las anteriores.

El vencimiento operaba de la misma manera. Cuando terminaba la vida de una fila, el agente debía borrarla y conservar las otras que aún no habían vencido. No enviaba una Registration Reply sólo por ese vencimiento. La lista de visitantes del agente extranjero podía extinguirse naturalmente, quizá al mismo tiempo.

Incluso un duplicado exacto de una solicitud ya aceptada tenía un límite: no podía prolongar la vida más allá de la concesión original. El Identification enlazaba solicitud y respuesta y participaba en la protección contra replay, pero no convertía una retransmisión en permiso nuevo.

El diseño posterior separó copia y política

RFC 3344 se publicó en agosto de 2002 y sustituyó a RFC 3220, que a su vez continuaba RFC 2002. RFC 5944 lo reemplazó en 2010 y mantuvo la posibilidad de registrar varias care-of y enviar una copia a cada una. Los dos registros de errata de RFC 3344 —uno editorial retenido y otro técnico rechazado— no alteran esta regla.

En IPv6, RFC 3775 habló de una care-of primaria y de conservar temporalmente la primaria anterior durante el traspaso. RFC 5648 añadió identificadores para distinguir varias vinculaciones. Años después, el RFC experimental 7629 llevó identificadores y políticas de flujo a Mobile IPv4, con varios túneles utilizables de forma más selectiva.

El contraste importa. El bit S de RFC 3344 no informaba cuál camino era mejor, saludable o barato. Ordenaba replicación general. Una entrada activa podía ofrecer resiliencia, consumir capacidad sin beneficio o apuntar a un extremo que ya no entregaba. El estado de control no resolvía el resultado operativo.

La lección histórica cabe en una regla: una tabla plural necesita pruebas plurales. Hay que conservar la intención S, el código aceptado, cada dirección, cada duración, cada copia enviada y cada recepción observada. El registro más reciente no tiene derecho automático a borrar el pasado.

Fuentes