¿Linux almacena en caché los RA?

¿Linux almacena en caché los RA?

Debido aun error en OpenBSD rtadvd, mi enrutador a veces envía RA con un prefijo incorrecto

prefix 2001:41d0:fe4b:ecf1::/64
prefix 2001:41d0:fe4b:ec42::/64
prefix 2a01:e35:8aea:ac42::/64

Pero si lo arreglo para que solo envíe los prefijos correctos ( 2001:41d0:fe4b:ec42::/64y prefix 2a01:e35:8aea:ac42::/64), yborrar la direccióndesde la interfaz, mi máquina Linux sigue asignando IPv6 desde el prefijo erróneo cada vez que recibe un RA del enrutador.

15:46:44.138257 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::8621:df60:6d70:8da > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 136
    hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
      source link-address option (1), length 8 (1): 00:00:24:d1:42:0d
        0x0000:  0000 24d1 420d
      prefix info option (3), length 32 (4): 2a01:e35:8aea:ac42::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
        0x0000:  40c0 0027 8d00 0009 3a80 0000 0000 2a01
        0x0010:  0e35 8aea ac42 0000 0000 0000 0000
      prefix info option (3), length 32 (4): 2001:41d0:fe4b:ec42::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
        0x0000:  40c0 0027 8d00 0009 3a80 0000 0000 2001
        0x0010:  41d0 fe4b ec42 0000 0000 0000 0000
      rdnss option (25), length 24 (3):  lifetime 900s, addr: 2a01:e35:8aea:ac42::10
        0x0000:  0000 0000 0384 2a01 0e35 8aea ac42 0000
        0x0010:  0000 0000 0010
      dnssl option (31), length 24 (3):  lifetime 900s, domain(s): geekwu.org.
        0x0000:  0000 0000 0384 0667 6565 6b77 7503 6f72
        0x0010:  6700 0000 0000
15:46:44.553069 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) :: > ff02::1:ffd1:28d4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:41d0:fe4b:ecf1:8581:1b57:b9d1:28d4
      unknown option (14), length 8 (1): 
        0x0000:  1d76 c406 8db8

Puedes ver el RA con solo 2 prefijos, y luego el neighbor solicitationpaquete, que es mi casilla marcando que la dirección es "libre" (DAD)... y lo es, ya que este prefijo no está en uso en este enlace ethernet. Como esta dirección es la última insertada, es la predeterminada para las conexiones salientes, pero el enrutador no puede enrutarla de regreso porque no está definida.

Sólo puedo suponer que el kernel, o algo en el área de usuario, mantiene el RA antiguo en caché, por cualquier motivo, y lo usa en lugar del RA "vivo" (¿o tal vez los fusiona?)

Si es así, ¿hay alguna forma de verlo? ¿vaciar o alterar este caché? Probablemente pueda rebotar mi caja, pero, bueno... parece malo.

(núcleo 4.16.13-1-ARCH)

EDITAR:

Envié un RA con scapy para este prefijo, con una duración de 0, y la dirección deja de agregarse para cada RA posterior.

Welcome to Scapy (unknown.version)
>>> a = IPv6()
>>> a.dst = "ff02::1"
>>> b = ICMPv6ND_RA()
>>> b.display()
>>> c = ICMPv6NDOptSrcLLAddr()
>>> c.lladdr = "00:00:24:d1:42:0d"
>>> d = ICMPv6NDOptMTU()
>>> e = ICMPv6NDOptPrefixInfo()
>>> e.prefixlen = 64
>>> e.prefix = "2001:41d0:fe4b:ecf1::"
>>> e.preferredlifetime=0
>>> e.validlifetime=0
>>> send(a/b/c/d/e)

NetworkManager (1.10.8) se está ejecutando en este cuadro, con la configuración predeterminada

Respuesta1

Este parece el resultado esperado.

SLAAC permite que varios enrutadores anuncien diferentes conjuntos de prefijos y, por lo tanto, nuevos RAnoinvalidar los anteriores, sólo actualizarlos de forma incremental.

Una vez que se ha configurado un prefijo, permanece durante su vida útil "válida" (actualizada por cada nueva RA), a menos que una RAexplícitamenteestablece la vida útil de ese prefijo en cero. (VerRFC 4862.)

información relacionada