Resumen

  • Desde el diseño temprano de SLAAC, una dirección IPv6 puede pasar de preferred a deprecated sin quedar invalidada. El primer reloj guía nuevas comunicaciones; el segundo determina si la dirección sigue asignada.
  • La separación permite que un prefijo nuevo reciba las conexiones futuras mientras el antiguo conserva las sesiones que no pueden cambiar de extremo a mitad de camino.
  • La protección de dos horas contra anuncios falsificados limita la invalidación rápida. Cuando un router olvida el prefijo anterior tras reiniciarse, esa misma cautela puede alargar una configuración que ya no sirve.

IPv6 inventó una vejez útil

El RFC 1971, publicado en 1996, no trató la retirada de una dirección como un salto único. Mientras su tiempo preferido sigue vigente, la dirección puede emplearse libremente. Cuando ese tiempo termina, pasa a estado deprecated: ya no conviene escogerla para trabajo nuevo, pero continúa siendo válida. Solo al agotarse Valid Lifetime queda invalid y desaparece su asociación con la interfaz.

La fase intermedia responde a una limitación concreta. Una conexión TCP abierta suele conservar las mismas direcciones durante toda su vida. Si el host eliminara el extremo antiguo en cuanto aparece un prefijo nuevo, rompería sesiones cuyo único defecto es haber comenzado antes de la renumeración. Una dirección obsoleta puede seguir recibiendo paquetes y servir de origen a esas comunicaciones cuando cambiarla cause perjuicio.

Por eso obsoleta no significa inaccesible. La primera expiración cambia una preferencia; la segunda retira autoridad para usar o reconocer la dirección. Confundirlas lleva a diagnósticos opuestos: considerar una transición cuidadosamente solapada como un fallo, o creer que una dirección aún visible sigue siendo una buena elección para conexiones nuevas.

El anuncio lleva dos relojes, no una fecha de caducidad

El RFC 4861 define ambos campos en la opción Prefix Information de Router Advertisement. Son valores de 32 bits expresados en segundos; todos los bits a uno representan infinito. El tiempo preferido nunca puede superar al válido. El RFC 4862 manda ignorar una opción que invierta ese orden.

La opción también contiene el indicador Autonomous. Sin él, esos números no autorizan por sí solos a formar una dirección mediante SLAAC. El prefijo, el indicador y los tiempos tienen significados complementarios: extraer un reloj de esa estructura borra quién puede usarlo y para qué.

Los Router Advertisements llegan de manera periódica. Repetir una duración fija renueva el horizonte con cada recepción; anunciar una cifra decreciente puede apuntar a una hora de retirada definida. La ausencia del prefijo en un anuncio concreto no equivale a revocación. Ese paquete quizá repartió las opciones, omitió algunas deliberadamente o simplemente fue el único que llegó. El host conserva el estado hasta que recibe una instrucción aplicable o expira el reloj conocido.

La selección predeterminada empuja sin expulsar

El RFC 6724 incorpora la distinción al algoritmo de selección de origen. Su regla 3 prefiere una dirección no obsoleta frente a una obsoleta. Así, una interfaz puede mantener dos identidades durante la transición: la nueva gana las conexiones que comienzan; la vieja sostiene las que ya existen.

La regla es una preferencia predeterminada, no una prohibición universal. Una aplicación que especifica explícitamente un origen válido puede conservarlo. Una conexión recibida en la dirección antigua todavía puede contestarse desde ella. El host debe aceptar tráfico dirigido a una dirección obsoleta mientras siga dentro del tiempo válido.

La evidencia necesaria también se divide. Ver una dirección en la interfaz prueba presencia, no preferencia. Ver estado deprecated prueba una política de selección, no una caída del camino. Observar que una conexión antigua sigue viva no prueba que las nuevas estén abandonando el prefijo. Para entender la transición hay que mirar estado, reloj, ruta y decisiones de origen por separado.

Una duración preferida de cero inicia el drenaje

Un operador puede publicar el prefijo antiguo con Preferred Lifetime igual a cero y mantener un Valid Lifetime positivo. El cambio de estado es inmediato: el host evita esa fuente para nuevas comunicaciones, pero no borra la dirección. El reemplazo empieza a recibir demanda sin exigir que cada sesión vieja termine en el mismo instante.

El RFC 5887 sitúa esta convivencia en el centro de una renumeración planificada. Primero aparece el prefijo nuevo; después se reduce la preferencia del antiguo; finalmente se deja expirar o se invalida cuando las dependencias han drenado. Sin embargo, el texto también advierte que renumerar sigue requiriendo trabajo fuera de SLAAC.

DNS, tablas de rutas, listas de control, firewalls, certificados, registros operativos y configuraciones de aplicaciones no obedecen automáticamente a los dos relojes. Una dirección puede ser válida en el host mientras el proveedor ya no enruta su prefijo. Puede dejar de ser preferida y seguir publicada en un nombre. Los tiempos ofrecen una señal común, no una transacción distribuida entre todas esas superficies.

La red desconfía más de una muerte que de una jubilación

Un Router Advertisement no autenticado puede ser falsificado por alguien con acceso al enlace. Permitir que reduzca Valid Lifetime a unos segundos daría al atacante poder para eliminar las direcciones de un host. El RFC 4862 limita ese daño con la regla de dos horas. Si quedaba más tiempo, un valor pequeño no autenticado normalmente solo puede llevar la expiración hasta ese umbral. Si ya quedaban dos horas o menos, una reducción adicional se ignora para el reloj válido.

El tiempo preferido recibe un trato distinto: se actualiza con el valor anunciado aunque la reducción del válido quede amortiguada. La razón está en el impacto. Obligar a una dirección a ceder nuevas conexiones es menos destructivo que hacerla desaparecer; además, impedir una deprecación rápida frustraría una renumeración legítima.

Un anuncio autenticado puede permitir otra decisión. La regla no autoriza a afirmar que los anuncios observados tengan autenticación ni convierte dos horas en una espera obligatoria para cualquier retirada. Es un límite de poder frente a evidencia débil.

El reinicio puede borrar la capacidad de despedirse

La transición ordenada presupone que el router recuerda el prefijo anterior. En una red doméstica, el equipo puede reiniciarse, obtener un prefijo delegado distinto y perder el dato que publicaba antes. Sabe anunciar lo nuevo, pero ya no sabe qué opción antigua debe enviar con tiempos nulos.

El RFC 8978 estudia este escenario de flash renumbering. Sin retirada explícita, los hosts esperan los últimos relojes recibidos. El documento usa los valores predeterminados del RFC 4861 —siete días de preferencia y treinta de validez— para mostrar que el estado obsoleto puede durar días. No son mediciones de equipos actuales; son el alcance temporal de una promesa no cancelada.

Incluso si el router conserva el dato y envía cero, la protección de dos horas puede impedir la invalidación inmediata de un mensaje no autenticado. La defensa frente a una falsificación y la recuperación rápida tras perder un prefijo compiten por el mismo mando.

Retirar exige memoria estable y repetición

El RFC 9096 recomienda que los routers de borde de cliente guarden en almacenamiento estable los prefijos anunciados, coordinen los tiempos del lado LAN con la delegación aguas arriba y publiquen los prefijos antiguos con ambas duraciones a cero después del cambio.

También deben repetir la señal. Un host puede perder el anuncio que contenía la retirada; por eso el router necesita seguir nombrando el estado antiguo durante un intervalo relacionado con la validez previamente prometida. La revocación fiable no está completa cuando sale el primer paquete.

Estas recomendaciones no demuestran adopción. Hacen visible una dependencia: quien crea y refresca estado temporal necesita conservar un inventario de lo creado. De lo contrario, el reinicio preserva el mecanismo de renovación pero elimina el vocabulario de cierre.