Resumen

  • En RFC 5203, anunciar un tipo, pedirlo, autorizar el registro, crear estado y usar el servicio son actos distintos con pruebas distintas.
  • REG_RESPONSE da constancia de tipos concedidos y una vida útil; el estado es blando, puede cancelarse y no sustituye el acuse del componente que presta el servicio.
  • La operación fiable conserva las dos copias del registro, el estado específico del servicio, los cambios de configuración, el intento de uso y su desenlace.

El reinicio que no tocó la concesión

Un agente recibe permiso para registrarse en un servicio HIP y almacena una respuesta válida durante dos minutos. El proceso que oficia de registrador sigue funcionando. Otro proceso, responsable del servicio concreto, se reinicia y pierde su tabla en memoria.

Desde fuera, nada parece haber cambiado. La respuesta sigue firmada. La fecha de expiración sigue en el futuro. El registrador responde. Sin embargo, la siguiente operación no encuentra el estado que necesitaba.

El ejemplo es hipotético. No atribuye el comportamiento a ningún producto ni informa de un incidente. Sirve para mostrar una asimetría de recuperación: una capa puede conservar su evidencia mientras otra pierde la condición operativa que esa evidencia habilitaba.

Si el panel calcula salud con ahora < vencimiento, seguirá afirmando disponibilidad. Si exige un acuse del servicio después de cada reinicio o cambio de época, mostrará la realidad: registro vigente en una capa, estado desconocido en otra.

RFC 5203 normaliza el permiso, no la ejecución

El documento experimental de 2008 define una extensión genérica para que un host HIP se registre con servicios como un servidor de encuentro o un middlebox. Declara fuera de alcance el descubrimiento del servicio, la localización del registrador y la interacción posterior al registro.

Ese reparto evita que el mecanismo común imponga un modelo de ejecución a servicios diferentes. También impide leer en la respuesta genérica una afirmación que sólo puede emitir el servicio concreto.

La definición de registro habla de estado compartido por solicitante y registrador, con duración finita y posibilidad de renovación. Ese estado permite beneficiarse de la capacidad. Permitir no equivale a demostrar que se invocó, que estaba disponible en el momento de invocación o que produjo un resultado útil.

El texto añade que procesar con éxito la petición crea estado en el registrador y posiblemente en el servicio. La palabra marca una frontera de autoridad. El registrador sabe lo que admitió y almacenó. No por ello sabe automáticamente lo que un proceso adjunto conservó tras un fallo.

Cuatro parámetros, cuatro alcances

REG_INFO anuncia los tipos que el registrador puede y quiere ofrecer. Si condiciones transitorias le impiden prestar servicios, debería anunciar una lista vacía. Si la oferta vuelve o cambia, debería comunicar el conjunto actual mediante UPDATE.

REG_REQUEST expresa qué tipos solicita un host y durante cuánto tiempo los desea. El solicitante no debe pedir un tipo que no figurase en el anuncio aplicable. La petición está protegida, pero no decide.

El registrador autentica la identidad del host y consulta su política local. REG_RESPONSE devuelve los tipos autorizados y la duración concedida. REG_FAILED devuelve los no concedidos o fallidos. El RFC original distingue, entre otros, credenciales adicionales e indisponibilidad del tipo.

El error de modelado aparece al sustituir los cuatro por una propiedad llamada servicio_activo. Se pierden la hora del anuncio, el contenido de la petición, la política que decidió, el alcance de la respuesta y la causa del fallo. Queda una luz sin procedencia.

La alternativa no exige un sistema pesado. Basta mantener estados separados y la relación entre ellos: anuncio recibido, solicitud enviada, concesión procesada y servicio confirmado. Sólo el último componente puede decir que está preparado para actuar.

La vida útil es revocable

La duración que pide el solicitante no obliga al registrador. Éste puede devolver otra, y el solicitante debe estar preparado incluso cuando su valor pedido caía entre el mínimo y el máximo anunciados.

La duración concedida gobierna el registro. No es una reserva irrevocable de capacidad. El valor cero cancela. El solicitante puede cancelar antes. El registrador o el servicio adjunto también puede hacerlo cuando ya no puede prestar la capacidad, por cambio de configuración o presión de recursos.

Por eso un solo expires_at no describe el sistema. Hacen falta al menos: instante de creación, último refresco, época de configuración, cancelación emitida, cancelación observada y vencimiento. Si el servicio tiene estado propio, necesita su identificador y su propia causal de eliminación.

Tampoco vale la inferencia «no vi una cancelación, luego todo sigue bien». El RFC recomienda enviar una respuesta de duración cero, pero el mensaje puede perderse o no procesarse. El silencio conserva incertidumbre. No la convierte en continuidad.

La criptografía no extiende el sujeto de la frase

Una concesión HIP protegida merece confianza dentro de su alcance. La identidad del solicitante fue autenticada y el registrador aplicó su política. Negar ese valor sería tan incorrecto como ampliarlo.

La firma acredita quién dijo qué. No añade que un servicio mantuvo memoria, que una ruta siguió disponible o que una transacción terminó. La semántica del contenido sigue siendo la misma después de verificar la firma.

En sistemas de automatización ocurre con frecuencia lo contrario: cuanto más sólido parece el artefacto criptográfico, más usos secundarios se le asignan. Una respuesta de admisión termina habilitando sondeos, suprimiendo alarmas o justificando una auditoría de entrega.

El diseño correcto conserva el objeto firmado con sus dimensiones: identidad, tipos, duración, política y época. Después enlaza recibos emitidos por los actores que sí observan las etapas siguientes.

La sustitución por RFC 8003 no convirtió el registro en SLA

RFC 8003 reemplazó a RFC 5203 en 2016 y llevó el mecanismo a Standards Track. Incorporó una autorización por certificados más detallada, precisó la disposición frente a cada solicitante y añadió un fallo por recursos insuficientes.

Son mejoras importantes para explicar por qué no se admite un registro. El solicitante puede distinguir falta de credenciales, certificado inválido, tipo no disponible o falta temporal de recursos. Sin embargo, se mantienen el anuncio, la petición, la respuesta, el fallo, la vida finita y la cancelación.

El sucesor no afirma que la respuesta genérica sea prueba de uso. La separación de servicio específico sigue presente. Una taxonomía de fallos más rica no es telemetría de ejecución.

La propia obsolescencia debe tratarse con cuidado. RFC 5203 es una pieza histórica, no la especificación vigente. RFC 8003 es la referencia posterior. Ninguna fecha de publicación revela qué binario o configuración opera en una red concreta.

El servicio debe cerrar la cadena

Los tipos de registro pueden definir dependencias y parámetros HIP adicionales. Esa extensión localizada es coherente con un núcleo mínimo: la mecánica común registra; el tipo concreto explica qué significa preparar y usar la capacidad.

Un servicio de rendezvous necesitará evidencia de la vinculación almacenada y, más adelante, del mensaje recibido y reenviado. Un servicio de middlebox necesitará la regla exacta, el dispositivo, la política, el tiempo y los paquetes que coincidieron. No hay un recibo universal para ambos.

La secuencia operativa puede expresarse así:

ofrecido → solicitado → autorizado → almacenado en registrador → almacenado en servicio → usado → resultado.

Cada flecha puede fallar sin invalidar necesariamente los hechos anteriores. Un registro autorizado puede perder el estado de servicio. Un servicio listo puede no ver tráfico. El tráfico puede llegar y la aplicación rechazarlo. Mantener estas diferencias acelera la investigación en lugar de complicarla.

Qué guardar después del reinicio

El expediente mínimo incluye:

  • versión HIP y extensión, compilación y configuración;
  • HIT del solicitante y del registrador;
  • huella, hora, tipos y vidas de REG_INFO;
  • huella, tipos y duración de REG_REQUEST;
  • identidad autenticada, credenciales, política y responsable;
  • huella de REG_RESPONSE o REG_FAILED, resultado y vida concedida;
  • estados local y remoto, refrescos, vencimientos y época de reinicio;
  • identificador y acuse del servicio adjunto;
  • cancelaciones, expulsiones y cambios de configuración;
  • operación específica intentada, trayecto y resultado;
  • incógnitas explícitas.

Con este registro, una recuperación no hereda confianza de una época anterior sin justificación. El registrador puede volver a validar su estado. El servicio puede declarar que su tabla está vacía. El controlador sabe qué prueba debe renovar.

La enseñanza útil de RFC 5203 no es desconfiar del registro. Es reconocer que el registro tiene un objeto preciso. Cuando el servicio desaparece, la concesión histórica sigue diciendo la verdad histórica; lo que deja de decir es algo que nunca estuvo en ella.

Fuentes