IPv6 RA SLAAC prefijo de por vida

Por lo que entiendo, no hay forma de cambiar la vida útil del prefijo una vez que los hosts instalan el prefijo. Si acorto el temporizador válido / preferido para un prefijo, ¿no tiene efecto en los hosts que ya usan el prefijo con SLAAC hasta que el host intente renovar la dirección? A diferencia de la vida útil de RA (para fines de la puerta de enlace predeterminada), la vida útil de RA se extiende al recibir un mensaje de RA. ¿Alguien puede señalarme la sección RFC para el proceso de renovación de prefijo / puerta de enlace predeterminada?

Lo que quiero lograr es eliminar un prefijo SLAAC a través de la red antes de que expire la vigencia válida, ¿hay alguna forma de hacerlo? En el lado del enrutador o en el lado de acceso / host. Probé en IOS 12.4 incluso cerrado / no cerrado, una interfaz no eliminará el prefijo aprendido de SLAAC. Puedo configurar otro prefijo pero no quiero que los hosts sigan usando el anterior.

Creo que vi en algún lugar RA con un prefijo de por vida = 0 puede marcar un prefijo para su eliminación, ¿es esto un RFC o solo algo específico del proveedor? Si existe tal cosa, ¿cómo puedo forzar la regeneración de este mensaje en caso de que algunos hosts pierdan el primero?

¿Cuál es la directriz para configurar la vida útil de RA / prefijo? ¿Qué tan corto puede ser? HA consideraciones de diseño?

Gracias

Para la asignación de prefijos utilizando SLAAC (RFC 4862), las vidas están completamente regidas por la descripción en la sección 5.5.3. Procesador de publicidad de enrutadores . Simplificar:

1. Si el prefijo aún no se usa, puede usarlo con las vidas preferidas y válidas que se indican, sin restricciones.
2. Si el prefijo ya está en uso, actualice la vida útil preferida con el valor señalado, sin restricciones. Para el tiempo de vida válido, el tiempo de vida válido señalado ( signaled) debe compararse con el tiempo de vida válido restante actual ( remaining).
   1. Si remaining<signaled: solo actualízalo, sin restricciones.
   2. Si signaled<remaining: Tenga cuidado, esto podría ser un ataque de DOS, solo actualícelo si signaled > 2h(o la fuente está autenticada). 2h debería ser suficiente tiempo para permitir que aparezca un RA válido con temporizadores correctos.

En resumen, cuando se trata de desaprobación, puede asegurarse de que una dirección SLAAC ya no se use para nuevas conexiones (establezca el tiempo de vida preferido en 0) pero no puede eliminar las sesiones en curso mientras se esté ejecutando el tiempo de vida válido. Por supuesto, varias implementaciones pueden proporcionar interfaces administrativas para eliminar forzosamente una dirección, pero eso está fuera del alcance de RFC.

En lo que respecta al RFC, puede poner la vida útil preferida a cualquier cosa, aunque 0no tiene sentido. La vida útil válida no puede ser 0excepto cuando se desprecia. Preferido siempre debe ser más grande que válido. Entonces, a qué hora lo pones es tu elección y depende de tu caso de uso.

Lo que RFC 4862 establece sobre la duración de los prefijos no tiene nada que ver con SLAAC, esto es puro sobre cuánto tiempo son válidos los prefijos en el enlace para realizar el descubrimiento de vecinos.

RFC4861 sección 6.3.4. Procesamiento de anuncios de enrutadores recibidos: - Si el prefijo ya está presente en la Lista de prefijos del host como resultado de un anuncio recibido anteriormente, restablezca su temporizador de invalidación al valor Válido de por vida en la opción Información de prefijo. Si el nuevo valor de Lifetime es cero, agote el prefijo inmediatamente (consulte la Sección 6.3.5).

Sin embargo, el host no olvida inmediatamente el prefijo, al menos si la implementación es sólida y sigue RFC4862. Existen reglas adicionales para el manejo de la vida útil del prefijo: consulte RFC4862 sección 5.5.3. Procesamiento de anuncios de enrutador, punto e) más específico. Hay 2 horas de período de "seguridad" antes de descartar el prefijo.

Al seleccionar las vidas, mantenga la vida preferida <= vida útil válida!