O Linux está armazenando RAs em cache?

O Linux está armazenando RAs em cache?

Devido aum bug no OpenBSD rtadvd, meu roteador às vezes envia RA com um prefixo incorreto

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

Mas se eu corrigir isso, ele enviará apenas os prefixos corretos ( 2001:41d0:fe4b:ec42::/64e prefix 2a01:e35:8aea:ac42::/64), eexclua o endereçoda interface, minha caixa Linux continua atribuindo IPv6 do prefixo incorreto cada vez que obtém um RA do roteador.

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

Você pode ver o RA com apenas 2 prefixos, e depois o neighbor solicitationpacote, que é minha caixa marcando se o endereço é "livre" (DAD)... e é, pois esse prefixo não está em uso neste link ethernet. Como este endereço é o último inserido, é o padrão para conexões de saída, mas o roteador não pode roteá-lo de volta, pois não está definido.

Só posso adivinhar que o kernel - ou algo no mundo do usuário - está mantendo o antigo RA em cache, por qualquer motivo, e o usa em vez do RA "ao vivo" (ou talvez os mescle?)

Se sim, existe alguma maneira de ver isso? liberar ou alterar esse cache? Provavelmente posso refazer minha caixa, mas, bem... parece ruim.

(kernel 4.16.13-1-ARCH)

EDITAR:

Enviei um RA com scapy para este prefixo, com tempo de vida 0, e o endereço deixa de ser adicionado para cada RA subsequente.

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) está sendo executado nesta caixa, com configuração padrão

Responder1

Este parece ser o resultado esperado.

O SLAAC permite que vários roteadores anunciem diferentes conjuntos de prefixos, portanto, novos RAsnãoinvalidar os anteriores, apenas atualizá-los de forma incremental.

Depois que um prefixo for configurado, ele permanecerá durante seu tempo de vida "válido" (atualizado por cada novo RA), a menos que um RAexplicitamentedefine o tempo de vida desse prefixo como zero. (VerRFC 4862.)

informação relacionada