☰

Linux は RA をキャッシュしていますか?

tag-icon • tag-icon linux networking arch-linux ipv6
Linux は RA をキャッシュしていますか?

によりOpenBSD rtadvd のバグルータが間違ったプレフィックスでRAを送信することがあります

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

しかし、正しいプレフィックス（2001:41d0:fe4b:ec42::/64とprefix 2a01:e35:8aea:ac42::/64）のみを送信するように修正すると、アドレスを削除するインターフェースから、私の Linux ボックスは、ルーターから RA を取得するたびに、誤ったプレフィックスから IPv6 を割り当て続けます。

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

プレフィックスが 2 つだけの RA と、その次にneighbor solicitationパケットが表示されます。このボックスでは、アドレスが「フリー」(DAD) であるかどうかがチェックされています。実際、このプレフィックスはこのイーサネット リンクでは使用されていないため、フリーになっています。このアドレスは最後に挿入されたものなので、発信接続のデフォルト アドレスになりますが、定義されていないため、ルータはこれをルーティングできません。

カーネル、またはユーザーランドの何かが、何らかの理由で古い RA をキャッシュに保持し、それを「ライブ」RA の代わりに使用している (またはそれらをマージしている) としか推測できません。

もしそうなら、それを確認する方法はありますか? このキャッシュをフラッシュまたは変更する方法はありますか? おそらくボックスを再起動することはできますが、まあ... 良くないようです。

(カーネル 4.16.13-1-ARCH)

編集：

このプレフィックスに対して、有効期間 0 の RA を scapy で送信しましたが、後続の RA ごとにアドレスが追加されなくなります。

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）がデフォルト設定で実行されています

答え1

これは予想通りの結果のようです。

SLAACでは、複数のルータが異なるプレフィックスセットをアドバタイズできるため、新しいRAがしないでください以前のものを無効にし、増分的にのみ更新します。

プレフィックスが設定されると、RAが変更しない限り、そのプレフィックスは「有効な」存続期間中（新しいRAごとに更新される）そのまま残ります。明示的にそのプレフィックスの有効期間をゼロに設定します。（RFC 4862。

関連情報