Resumen
- La renumeración IPv6 es un cambio con coexistencia, no una sola orden de enrutamiento: prefijos viejo y nuevo deben funcionar a la vez mientras rutas, filtros, direcciones, DNS y dependencias avanzan a ritmos distintos.
- Inferencia operativa: las vidas preferida y válida, los plazos de prefijos delegados y resolutores, las cachés DNS positivas y negativas, la selección de origen y las sesiones largas forman un único límite de decisión.
- La reversión no es una transacción atómica del protocolo. Debe probarse mientras el operador conserve el prefijo antiguo, la zona inversa y ambos caminos de tráfico.
Una migración que ya se ha partido
En una sucursal, el nuevo agregado ya es visible aguas arriba y la zona autoritativa publica el nuevo registro AAAA. Una sonda alcanza el servicio por esa dirección. Sin embargo, el router local conserva el prefijo delegado anterior, un resolutor recursivo sigue sirviendo la respuesta vieja y una sesión de base de datos continúa ligada a esa dirección. Los flujos nuevos dejan de elegirla cuando queda obsoleta; la sesión establecida no se traslada por sí sola.
Cada sistema dice algo cierto: la ruta está activa, el DNS cambió, el cliente tiene una dirección nueva y el servicio responde. La operación puede seguir siendo insegura porque esas verdades corresponden a relojes diferentes.
El RFC 4192 describe una renumeración sin día de corte: desplegar el prefijo nuevo sin apagar el antiguo, llegar a un estado estable con ambos, trasladar el uso y retirar lo viejo al final. Es un esqueleto que debe adaptarse, no una receta universal. El protocolo aporta mecanismos; el operador debe aportar la prueba.
El prefijo está en más sitios que la ruta
Una dirección IPv6 aparece en planes de enlaces, interfaces de routers, Router Advertisements, DHCPv6, delegación de prefijos, filtros de entrada y salida, ACL, configuración de servicios, DNS directo e inverso, listas de permiso, monitorización y cachés de aplicaciones. El RFC 6879 incorpora las configuraciones manuales, las sesiones duraderas y los sistemas que están fuera del control directo del equipo de red.
Por eso el inventario es parte de la prueba. No encontrar literales ayuda, pero no basta: una dirección puede derivarse de un prefijo, permanecer en memoria, figurar en el filtro de un socio o residir en una sucursal que estuvo desconectada. El recibo debe indicar qué superficie se revisó, con qué versión de cambio, quién la verificó y qué excepciones quedan.
Preferida no significa válida, y válida no significa usada
El RFC 4862 asigna dos relojes a una dirección autoconfigurada. Cuando termina la vida preferida, la dirección queda obsoleta. Cuando termina la vida válida, deja de ser válida. El RFC 6724 da prioridad a evitar direcciones de origen obsoletas si existe una alternativa preferida.
La obsolescencia modifica la selección de nuevas comunicaciones. No demuestra que las sesiones antiguas hayan terminado, que un proceso refrescara el par almacenado ni que un cliente entrante dejara de usar un AAAA antiguo. Mantener válida la dirección anterior conserva una vía de recuperación, pero puede ocultar dependencias si no se mide el tráfico por prefijo y antigüedad del flujo.
La regla de dos horas del RFC 4862 limita además cuánto puede reducir una Router Advertisement no autenticada la vida válida restante. Esta defensa evita que un anuncio falso invalide direcciones de inmediato. También impide suponer que una orden de emergencia será un interruptor universal. El plan debe reflejar lo que hacen los hosts, no solo lo que muestra el controlador.
La sucursal y el resolutor tienen relojes propios
El RFC 8415 transporta vidas preferidas y válidas para direcciones y prefijos delegados, además del proceso de renovación y rebinding. Un equipo de cliente puede conservar un IA_PD antiguo cuando la ruta superior, un host SLAAC y la zona autoritativa ya cambiaron. Una sede ausente durante todo el solapamiento puede volver con un estado local que nunca fue probado.
El RFC 8978 muestra que un prefijo SLAAC obsoleto puede persistir tras una renumeración rápida. El RFC 9096 recomienda coordinar las vidas anunciadas por Router Advertisement con la validez restante del prefijo delegado. Son consideraciones operativas, no una garantía de comportamiento uniforme de todos los routers de cliente. El RFC 4472 advierte además que una aplicación duradera puede conservar resultados DNS más allá del TTL del registro; exige medir la aplicación, no supone una duración universal de caché.
DNS añade varios relojes. Los TTL gobiernan registros AAAA y PTR almacenados. La publicación entre servidores autoritativos tiene su propio plazo. Las direcciones de resolutor y listas de búsqueda aprendidas por Router Advertisement disponen de vidas RDNSS y DNSSL bajo el RFC 8106. Renumerar el servicio y renumerar el resolutor que permite localizarlo son dos transiciones.
Las respuestas positivas no agotan el problema. El RFC 2308 define caché negativa. Si un resolutor consultó el nombre nuevo antes de que existiera, puede seguir respondiendo negativamente tras su publicación. Medir únicamente el TTL de AAAA no acota ese fallo.
El RFC 4861 completa la superficie local: los hosts interpretan con el tiempo la información de routers y prefijos de las Router Advertisements. Hay que observar lo aprendido por el host, no solo la configuración que debía emitir el router.
La convergencia es el máximo, no el promedio
Inferencia operativa: el modelo útil toma el máximo entre los relojes aún abiertos de ruta, filtro, PIO, IA_PD, RDNSS, caché positiva, caché negativa, caché de aplicación y sesión, más cualquier excepción estática que ni siquiera tenga temporizador.
Un promedio esconde la sucursal apagada, el resolutor con caché negativa más larga, el ACL de un socio que se modifica mediante ticket y el equipo que solo resuelve su servidor al arrancar. El denominador correcto incluye cada dependencia y punto de observación declarado, no solo los dispositivos que informaron durante la ventana.
Una sonda de ruta prueba alcance por el prefijo nuevo. Una consulta DNS prueba la respuesta actual de un resolutor. Un registro de flujos prueba el uso observado. Ninguno autoriza por separado la retirada. La evidencia decide cuando todas las observaciones se enlazan a la misma versión y al mismo libro de excepciones.
Fuentes
- RFC 4192 — renumeración IPv6 sin día de corte
- RFC 4862 — autoconfiguración IPv6
- RFC 6879 — renumeración de redes empresariales
- RFC 8106 — opciones DNS en Router Advertisements
- RFC 8415 — DHCPv6
- RFC 6724 — selección de direcciones IPv6
- RFC 2308 — caché negativa de DNS
- RFC 4861 — Neighbor Discovery para IPv6
- RFC 8978 — SLAAC reaction to flash-renumbering events
- RFC 9096 — customer-edge router reaction to IPv6 renumbering
- RFC 4472 — operational considerations and issues with IPv6 DNS
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

