Zachowanie informacji o trasie w systemie Linux IPv6 RA (24)

Zauważyłem dziwne zachowanie na jednej z moich maszyn z Linuksem 4.8.0 (Debian Sid)

Mój router usługodawcy internetowego wysyła adresy IPv6 RA w następujący sposób:

        IP6 (hlim 255, next-header ICMPv6 (58) payload length: 128) fe80::5667:51ff:fee7:7cf > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 128
        hop limit 64, Flags [other stateful], pref high, router lifetime 180s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): <prefix>::/64, Flags [onlink, auto], valid time 1138201s, pref. time 533401s
      route info option (24), length 24 (3):  <prefix>::/64, pref=medium, lifetime=1143629s
      rdnss option (25), length 40 (5):  lifetime 360s, addr: <dns1> addr: <dns2>
      mtu option (5), length 8 (1):  1500
      source link-address option (1), length 8 (1): 54:67:51:e7:07:cf

Powoduje to następującą tabelę routingu:

ip -6 r
<prefix>::/64 via fe80::5667:51ff:fee7:7cf dev eth0 proto ra metric 100  pref medium
fe80::5667:51ff:fee7:7cf dev eth0 proto static metric 100  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
default via fe80::5667:51ff:fee7:7cf dev eth0 proto static metric 100  pref medium

Pierwszy wpis jest nieparzysty. Cały ruch podsieci lokalnej jest przesyłany przez router, co nie jest zbyt optymalne. Mam także wartość accept_ra_rt_info_max_plen na 0.

Na moim innym komputerze w tej samej podsieci z Linuksem 4.7.0 (Debian Jessie) tabela routingu wygląda na oczekiwaną:

<prefix>::/64 dev eth0  proto kernel  metric 256  expires 1136467sec                       
fe80::/64 dev eth0  proto kernel  metric 256               
default via fe80::5667:51ff:fee7:7cf dev eth0  proto ra  metric 1024  expires 120sec hoplimit 64

Co może być powodem tego zachowania? Jak mogę zmodyfikować konfigurację, aby ruch w lokalnej podsieci nie był wysyłany przez router?

Są to odpowiednie bity reklamy routera:

prefix info option (3), length 32 (4): p/64, Flags [onlink, auto], valid time 1138201s, pref. time 533401s
route info option (24), length 24 (3): p/64, pref=medium, lifetime=1143629s

Opcja informacyjna prefiksu (PIO) mówi o tym prefiksie p/64 jest on-link. Mówi o tym opcja informacji o trasie (RIO) p/64 może być kierowany przez router.

Domyślnie Linux ignoruje RIO:

$ sysctl -a 2>&1 | grep wlan0.accept_ra_rt_info_max_plen
net.ipv6.conf.wlan0.accept_ra_rt_info_max_plen = 0

Dlatego oczekiwane jest zachowanie Jessie Debiana: opcja informacji o trasie jest ignorowana, prefiks on-link jest honorowany, a ty otrzymujesz trasę on-link. Na innym komputerze jakiś program lub inny prawdopodobnie zmienia wartość sysconf - spróbuj tego:

sysctl -a 2>&1 | grep rt_info_max_plen

Nie mogę znaleźć niczego w RFC 4191 na temat tego, czy RIO powinien zastąpić PIO, czy nie, więc przypuszczam, że zachowanie jest zgodne z RFC. Zgadzam się z tobą, że jest nieoptymalny.

Cały ruch podsieci lokalnej jest przesyłany przez router, co nie jest zbyt optymalne.

Nie jest tak źle. Pierwszy pakiet do każdego miejsca docelowego zostanie wysłany do routera, który wyśle ​​przekierowanie do nadawcy, co spowoduje wstawienie trasy przejściowej / 128 do miejsca docelowego i rozpoczęcie wysyłania pakietów bezpośrednio do miejsca docelowego. Tak, to solidny protokół.

Jak mogę zmodyfikować konfigurację, aby ruch w lokalnej podsieci nie był wysyłany przez router?

Powinieneś naprawić router, aby nie wysyłał fałszywego RIO. W przeciwnym razie powinieneś dowiedzieć się, który program zmienia wartość wspomnianego powyżej sysconf i wyłączyć go. Ale nie przejmowałbym się tym zbytnio - mechanizm przekierowania zajmie się sprawą w porządku.