Resumen

  • Las direcciones temporales acortan la ventana en la que un identificador IPv6 constante permite enlazar sesiones salientes; la siguiente dirección se prepara antes de que la anterior pierda su condición preferida.
  • “Obsoleta” no significa todavía inválida: la dirección deja de ser la opción normal para comunicaciones nuevas, pero puede sostener las ya establecidas hasta que termine su validez.
  • El mecanismo no aporta anonimato, cifrado ni autenticación. El prefijo, las direcciones estables, las cuentas, las cookies, los registros y el observador del enlace siguen ofreciendo continuidad.

Un observador registra una dirección hoy y vuelve a encontrar la misma parte identificadora después, quizá bajo otro prefijo. Para el observador, esa repetición es una ventaja: no necesita conocer al usuario ni descifrar la aplicación para sospechar que ambos intercambios proceden del mismo nodo. Las extensiones de privacidad de IPv6 se diseñaron para retirar esa ventaja con el tiempo, no para ocultar todos los demás rastros.

La interfaz puede conservar una dirección estable y, al mismo tiempo, elegir una temporal para la próxima sesión saliente. Antes de que esta última quede obsoleta, aparece una sucesora. La primera deja de iniciar trabajo nuevo, aunque sigue siendo válida para una conexión en curso. Más tarde, al vencer un segundo plazo, se vuelve inválida. La privacidad depende de esta secuencia disciplinada.

De la huella de hardware al ciclo de vida

La autoconfiguración sin estado forma una dirección IPv6 combinando el prefijo anunciado por un router con un identificador de interfaz. Cuando ese identificador se derivaba de un identificador IEEE globalmente único, podía mantenerse reconocible durante mucho tiempo. Cambiar de red alteraba el prefijo, pero no necesariamente la huella inferior de la dirección.

La RFC 3041, de enero de 2001, añadió direcciones globales con identificadores que cambiaban. Su función principal era iniciar sesiones salientes durante un periodo corto. Después se volvían obsoletas y eran sustituidas. La dirección anterior podía continuar una conexión establecida, pero no debía abrir la siguiente. El documento no eliminó el comportamiento normal de la autoconfiguración ni prometió que toda dirección estable desapareciera.

Eso hizo de la selección de origen una parte del control de privacidad. Generar una dirección temporal pero seguir eligiendo siempre la estable no cambia lo que ve el interlocutor. Elegir una temporal sin imponerle una vida limitada sólo crea otro identificador duradero. El diseño necesitaba generación, selección y expiración.

En septiembre de 2007, la RFC 4941 sustituyó a la RFC 3041. Exigió detección de direcciones duplicadas para cada dirección temporal, incorporó una opción de activación por prefijo, permitió identificadores diferentes para prefijos diferentes y dejó de limitar el algoritmo al uso de MD5. Aun así, recomendaba mantener desactivado el mecanismo por defecto. Mantenía un día como vida preferida sugerida y una semana como vida válida máxima sugerida.

La RFC 8981, publicada en febrero de 2021, volvió a cambiar esas decisiones. Eliminó la recomendación de desactivación por defecto. Exigió que las direcciones temporales del host usaran identificadores estadísticamente distintos, también entre prefijos e interfaces. Ordenó calcular un factor de desincronización para cada dirección, evitando que la rotación siguiera una cadencia fija. Y redujo la validez máxima por defecto de siete días a dos.

La trayectoria histórica muestra qué fallaba en una lectura demasiado simple de “aleatorio”. Reutilizar un identificador temporal bajo varios prefijos todavía permite unir observaciones. Rotar a intervalos exactos ayuda a predecir los cambios. Conservar durante una semana cada dirección antigua aumenta el solapamiento. La RFC 8981 trató esas tres propiedades como parte de la misma superficie.

El primer reloj cambia la elección

La RFC 4862 define la vida preferida como el tiempo durante el cual una dirección válida puede usarse sin restricciones. Cuando termina, la dirección pasa a estar obsoleta. Su empleo se desaconseja, pero no se prohíbe: una comunicación existente puede seguir usándola si cambiar de dirección causaría una interrupción. Una comunicación nueva debería elegir una dirección no obsoleta adecuada.

La vida válida marca otra frontera. Al terminar, la dirección deja de estar asignada a la interfaz. No puede enviarse tráfico con ella como origen ni reconocerse como destino. Por eso la obsolescencia no es una revocación instantánea y la invalidez no es sólo una preferencia menor.

La regeneración anticipada enlaza ambos relojes. La RFC 8981 pide iniciar la creación de la sucesora REGEN_ADVANCE antes de la obsolescencia. La generación y la detección de duplicados pueden tardar; comenzar antes evita que la interfaz se quede sin una dirección temporal preferida. En condiciones normales hay una sola dirección temporal no obsoleta por prefijo e interfaz, salvo durante ese breve relevo. Las obsoletas aún válidas pueden coexistir mientras las aplicaciones terminan.

Los valores de un día para TEMP_PREFERRED_LIFETIME y dos días para TEMP_VALID_LIFETIME son valores por defecto configurables, no una descripción universal. Las vidas anunciadas para el prefijo pueden acortarlos. DESYNC_FACTOR, distinto en cada dirección, resta un intervalo aleatorio a la vida preferida. Sin conocer la configuración y el anuncio, una captura no permite deducir el momento exacto de la siguiente rotación.

El cambio de enlace añade una decisión espacial. Al conectarse de verdad a otro enlace, la interfaz debe eliminar sus direcciones temporales anteriores y generar nuevas. Así, dos redes reciben identificadores aleatorios diferentes. Una implementación puede distinguir ese cambio de una caída y recuperación del mismo enlace, porque regenerar ante cualquier fluctuación crearía ruido y estado innecesarios.

Qué enlace rompe y cuáles conserva

La dirección IP queda expuesta a los pares, a los sistemas del camino y a los registros. Una parte identificadora constante puede agrupar transacciones que no comparten cuenta ni contenido. La rotación reduce la duración de ese enlace trivial. Las sesiones nuevas pasan a otra dirección; la dirección revelada por una comunicación también permanece alcanzable durante menos tiempo.

Sin embargo, el prefijo puede seguir identificando una vivienda, una empresa o un conjunto muy pequeño de hosts. Una dirección estable puede aparecer en otros flujos. El nombre DNS, la cookie, la cuenta autenticada o los registros del servicio pueden reunir sesiones. El router predeterminado puede observar todas las direcciones del host. Un observador en el camino puede comparar horarios y tamaños de paquetes aun cuando el contenido esté cifrado.

Por tanto, una dirección temporal no es una capa de cifrado: los encabezados siguen visibles. No autentica al usuario, al dispositivo ni al interlocutor. No garantiza anonimato y no borra la información ya comunicada. Si el usuario inicia sesión, quien recibe esa autenticación puede asociar la cuenta con la dirección temporal usada.

Tampoco puede suponerse siempre una dirección estable paralela. La RFC 8981 permite configurar direcciones temporales junto a estables o emplear sólo temporales. Esa libertad no amplía la garantía; restringe lo que puede inferirse de un paquete aislado. Ver una dirección rotar no revela todo el inventario del host ni explica por sí solo la causa.

El límite para las operaciones

Los equipos de red pagan un coste por perder una clave permanente. Un host puede ocupar varias filas de registro. Un problema repetido puede parecer obra de máquinas distintas. Un dispositivo de seguridad puede interpretar una regeneración rápida como falsificación. Las direcciones simultáneas consumen recursos de descubrimiento de vecinos y grupos multicast. Algunas aplicaciones esperan que varias sesiones compartan el mismo origen.

La observación útil debe combinar dirección y tiempo con el prefijo, el enlace o la interfaz, el estado de selección y, cuando proceda, el flujo o la sesión autenticada. Una dirección temporal prueba dónde estaba ese paquete en ese momento. No prueba una identidad duradera. Una conexión que continúa con una dirección obsoleta no demuestra que la rotación haya fallado; una conexión rota al invalidarse la dirección tampoco demuestra una migración segura.

El control está repartido. El router anuncia vidas del prefijo. El host crea y retira direcciones. El administrador define políticas globales o por prefijo. La aplicación puede necesitar una preferencia concreta. El interlocutor conserva sus registros. El estándar coordina estados, pero no concede a nadie un registro total del usuario.

La innovación fue hacer perecedera una clave visible sin fingir que toda observación perecía con ella. Esa precisión sigue siendo la mejor forma de explicar por qué una dirección que caduca puede proteger y, al mismo tiempo, dejar mucho por proteger.

Fuentes