Resumen

  • Los tres papeles de Mobile IP cuentan etapas distintas; retransmisión, pérdida, rechazo, reinicio y muestreo impiden equiparar totales sin una correlación externa.
  • La MIB es útil porque conserva diferencias entre observadores, no porque las borre en una cifra única de «servicio realizado».

Imaginemos una conciliación al final del turno. El agente extranjero dice haber recibido y reenviado solicitudes; el agente local conserva bindings y resultados de servicio; el nodo móvil registra envíos, respuestas y retransmisiones. RFC 2006 permite leer esos tres libros. No define un identificador de negocio común que convierta sus sumas en un único recibo.

Por eso una discrepancia no es automáticamente una avería y una coincidencia no es automáticamente una entrega. Una solicitud puede repetirse, perderse o ser rechazada; un agente puede reiniciarse; cada gestor puede sondear en otro instante. La primera obligación del operador es conservar esa multiplicidad antes de buscar una explicación.

La MIP-MIB, situada bajo mib-2 44, fue diseñada precisamente alrededor de las funciones del protocolo. Sus autores eligieron pocos objetos, útiles para configuración o diagnóstico y no derivables de otra MIB. El resultado es una contabilidad deliberadamente distribuida.

El libro del nodo móvil

mipEntities declara si el sistema soporta las funciones de nodo móvil, agente extranjero o agente local; puede marcar varias. mipEnable permite solicitar la activación o desactivación. mipEncapsulationSupported enumera capacidades. Son datos operativos valiosos, pero una función declarada no implica tráfico servido, ni una capacidad implica un túnel negociado o un paquete entregado.

En el nodo móvil, mnState distingue entre casa, registrado, pendiente, aislado y desconocido. La tabla de agentes extranjeros nace de anuncios recibidos y envejece cuando éstos caducan. Los contadores anotan solicitudes, anuncios, extensiones defectuosas y movimientos que el nodo «decidió» haber detectado. Un cambio de secuencia puede sugerir un reinicio del agente, pero no certifica su causa. Una fila todavía visible habla de memoria local, no de disponibilidad presente.

La tabla de registros reúne direcciones de agente y care-of, banderas, Identification, tiempo solicitado y restante, instante de envío y aceptación. Se actualiza a partir de solicitudes, respuestas y retransmisiones. Esa historia local no es una captura de paquetes, y el valor «aceptado» no convierte por sí mismo el registro en prueba de ubicación o servicio.

Dos libros más, sin clave de conciliación

El agente extranjero contabiliza solicitudes válidas recibidas y reenviadas, rechazos, respuestas y errores de autenticación o formato. El agente local mantiene bindings y contadores de servicio generales o por nodo. No se deben emparejar cifras parecidas como si designaran las mismas operaciones. Entre ambas funciones hay retransmisión, pérdida, rechazo, reinicio y diferentes momentos de observación.

Tampoco una fila de binding observa todo el recorrido. Muestra dirección de origen, home address, care-of address, banderas, Identification y vigencia que el agente local conserva. No demuestra que el paquete llegara al care-of address, fuera desencapsulado, cruzara el último enlace o alcanzara una aplicación.

El significado depende del tipo. Counter32 puede volver a cero por desbordamiento. Un Gauge32 de vida restante es una instantánea. TimeStamp usa el ciclo de sysUpTime, no un reloj civil independiente. La propia RFC cuenta el servicio acumulado desde el último reinicio del agente local. Sin época, intervalo y continuidad, una resta puede inventar una tendencia.

La excepción de seguridad tampoco cierra la identidad

La tabla de asociaciones de seguridad se indexa por dirección del par y SPI. La clave puede configurarse, pero al leerla debe aparecer una cadena de longitud cero: ocultación deliberada, no ausencia de clave. Los objetos de violación conservan el último contexto y la notificación opcional mipAuthFailure informa de una validación fallida.

La dirección reportada no identifica a una persona. El fallo tampoco distingue automáticamente un atacante, un equipo comprometido, un paquete falsificado o estado obsoleto, ni demuestra que el gestor recibiera todas las alertas. RFC 2006 hace visible una clasificación del agente; la investigación empieza a partir de ahí.

La consecuencia práctica no es desconfiar de los contadores, sino darles una contabilidad adecuada. Cada lectura necesita papel, instante, sysUpTime, política de acceso y motivo de actualización. Sólo después puede emparejarse con registros de control, capturas, identidad del equipo y observación de aplicación. RFC 2006 vuelve reconciliable una operación distribuida; no realiza la conciliación por el operador.

Fuentes