Comportamento do Linux IPv6 RA Route Information (24)

Question

Eu notei um comportamento estranho em uma das minhas máquinas com o Linux 4.8.0 (Debian Sid)

O roteador dos meus ISPs está enviando RAs IPv6 da seguinte forma:

        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

Isso resulta na seguinte tabela de roteamento:

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

A primeira entrada é ímpar. Todo o tráfego de sub-rede local está sendo encaminhado via roteador, o que não é muito ideal. Também aceito accept_ra_rt_info_max_plen como 0.

Na minha outra máquina na mesma sub-rede com a tabela de roteamento do Linux 4.7.0 (Debian Jessie) parece com o esperado:

<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

Qual pode ser o motivo desse comportamento? Como posso modificar minha configuração para que o tráfego para a sub-rede local não seja enviado via roteador?

    

Answer 1

Estes são os bits relevantes do anúncio do roteador:

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

A opção de informação de prefixo (PIO) diz que o prefixo p/64 está no link. A opção de informações de rota (RIO) diz que p/64 pode ser roteado pelo roteador.

Por padrão, o Linux ignora os RIOs:

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

Portanto, o comportamento do Debian Jessie é esperado: a opção de informações de rota é ignorada, o prefixo no link é respeitado e você obtém uma rota no link. Na outra máquina, algum software ou outro provavelmente está alterando o valor do sysconf - tente isto:

sysctl -a 2>&1 | grep rt_info_max_plen

Não consigo encontrar nada no RFC 4191 sobre se um RIO deve substituir um PIO ou não, então suponho que o comportamento seja compatível com o RFC. Eu concordo com você que é sub-ótimo.

All local subnet traffic is being forwarded via router which isn't very optimal.

Não é tão ruim assim. O primeiro pacote para cada destino será enviado para o roteador, que enviará um redirecionamento ao remetente, o que fará com que ele insira uma rota transitória / 128 para o destino e inicie o envio de pacotes diretamente para o destino. Sim, é um protocolo robusto.

How can I modify my config so traffic towards local subnet is not send via router?

Você deve consertar seu roteador para que ele não envie o RIO espúrio. Caso contrário, você deve descobrir qual parte do software está alterando o valor do sysconf mencionado acima e desativá-lo. Mas eu não me preocuparia muito com isso - o mecanismo de redirecionamento cuidará bem do assunto.