Percebi um problema de roteamento com IPv6 em nossa LAN. A maioria dos PCs clientes são thin clients LTSP. Eles obtêm um endereço por meio do SLAAC. Tracepath6para hosts na mesma sub-rede mostra que todo o tráfego é direto. Mas, o laptop em que estou trabalhando (Linux Mint 17, gerenciador de rede padrão), fornece a si mesmo dois endereços IPv6 e configura rotas para que todo o tráfego vá para o roteador primeiro, incluindo o tráfego na mesma sub-rede:
tracepath6 xxxx:1b0:5256:1337:10:50:0:8
1?: [LOCALHOST] 0.183ms pmtu 1500
1: xxxx:1b0:5256:1337:10:50:0:1 1.217ms
Perguntas:
1) Por que alguns hosts obtêm um e alguns hosts mais endereços? Tenho visto isso acontecer com mais frequência.
2) Por que esta máquina está optando por rotear todo o tráfego pelo roteador?
O roteador é dnsmasq, e de fato só tem SLAAC:
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: IPv6 router advertisement enabled
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: DHCP, IP range 10.102.20.1 -- 10.102.20.254, lease time 12h
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: DHCP, IP range 10.101.20.1 -- 10.101.20.254, lease time 12h
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: DHCP, IP range 10.100.0.100 -- 10.100.0.254, lease time 12h
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: DHCP, IP range 10.50.20.1 -- 10.50.20.254, lease time 12h
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: SLAAC on xxxx:1b0:5256:1337:: prefix valid 2h
Este é o meu eth0:
eth0 Link encap:Ethernet HWaddr 18:67:b0:34:2d:dd
inet addr:10.50.20.158 Bcast:10.50.255.255 Mask:255.255.0.0
inet6 addr: fe80::1a67:b0ff:fe34:2ddd/64 Scope:Link
inet6 addr: xxxx:1b0:5256:1337:2532:eb1a:1151:d2f0/64 Scope:Global
inet6 addr: xxxx:1b0:5256:1337:1a67:b0ff:fe34:2ddd/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12094 errors:0 dropped:0 overruns:0 frame:0
TX packets:17250 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2848542 (2.8 MB) TX bytes:3002689 (3.0 MB)
Estas são as rotas IPv4:
> route -n
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.50.0.1 0.0.0.0 UG 0 0 0 eth0
10.50.0.0 0.0.0.0 255.255.0.0 U 1 0 0 eth0
Estas são as rotas IPv6:
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
fe80::/64 :: U 256 1 0 eth0
::/0 fe80::213:3bff:fe0f:c02c UG 1 0 0 eth0
::/0 fe80::213:3bff:fe0f:c02c UGDAe 1024 0 0 eth0
::/0 :: !n -1 1 261 lo
::1/128 :: Un 0 3 243 lo
xxxx:1b0:5256:1337:1a67:b0ff:fe34:2ddd/128 :: Un 0 1 0 lo
xxxx:1b0:5256:1337:2532:eb1a:1151:d2f0/128 :: Un 0 1 86 lo
fe80::1a67:b0ff:fe34:2ddd/128 :: Un 0 1 178 lo
ff00::/8 :: U 256 1 0 eth0
::/0 :: !n -1 1 261 lo
A linha a seguir não está presente em hosts que acessam outros hosts diretamente:
::/0 fe80::213:3bff:fe0f:c02c UG 1 2 0 eth0
fe80::213:3bff:fe0f:c02cde fato, é o endereço de link local do roteador, do lado da LAN.
Editar: o comportamento que tenho visto pode ser aleatório. Reiniciei um dos thin clients várias vezes e um tracepath6 às vezes mostra o tráfego passando pelo roteador, às vezes diretamente para os hosts. É diferente quase a cada reinicialização, ao que parece. A tabela de roteamento é exatamente a mesma todas as vezes, também se eu ativar/desativar a opção dnsmasq off-link.
Edit2: O IPv4 sempre tem uma rota que indica que, para sua própria sub-rede, ele deve enviar apenas eth0, por exemplo. Então, quando adiciono essa rota no IPv6, o tráfego não passa mais pelo roteador:
/sbin/route -A inet6 add xxxx:1b0:5256:1337::/64 dev eth0
Então, por que xxxx:1b0:5256:1337::/64não está incluÃdo por padrão (em qualquer máquina aqui)? Não deveria estar presente uma rota que diga ao kernel que, para a sub-rede atual, basta enviar pela Ethernet (ou wlan, qualquer que seja)?
Edit3: Acabei de olhar com tcpdump+wireshark e vi que o Lsinalizador, On-Link, não está definido no anúncio do roteador, apesar de off-link não estar definido:
dhcp-range=xxxx:1b0:5256:1337::, ra-only, inifite
Os hosts IPv6 sempre obtêm um endereço de link local. Os outros endereços dependem de uma combinação dos sinalizadores no RA e das configurações do host. O RA pode sinalizar ao host que um servidor DHCPv6 pode distribuir endereços, nos quais o host pode agir. Se o RA contiver prefixos que permitem a configuração automática e o host não tiver desativado a configuração automática, o SLAAC será usado.
As especificações originais diziam que o ID da interface (os últimos 64 bits do endereço IPv6) são construÃdos a partir do endereço da camada de enlace (geralmente o endereço MAC). Mas seria possÃvel rastrear dispositivos pela Internet. Imagine um serviço Google ou Dropbox frequentemente contatado: em qualquer rede que você conectar seu laptop ou telefone celular, a sub-rede mudará, mas o ID da interface sempre será o mesmo. Portanto, os sistemas operacionais fornecem extensões de privacidade atualmente.
Extensões de privacidade fazem com que seu ID de interface mude regularmente. Os cronômetros exatos dependem da implementação, mas vamos supor que eles mudem a cada hora. A cada hora, seu dispositivo configura um novo endereço IPv6 para si mesmo. Endereços antigos são obsoletos e, quando o software para de usá-los, eles são removidos. Dessa forma, você pode acabar com vários endereços.
Além disso: quando um RA contém vários prefixos com o sinalizador de configuração automática definido, seu dispositivo configurará endereços em cada um deles.
Isso geralmente depende do sinalizador On-Link nos prefixos no RA. Se o sinalizador on-link estiver definido, o dispositivo pode criar uma rota para
/64a interface. Se o sinalizador não estiver definido, o dispositivo não poderá saber se os outros endereços no prefixo estão no link e enviará todos esses pacotes para o gateway padrão.É claro que seu dispositivo sempre pode escolher (intencionalmente ou por causa de um bug) ignorar o sinalizador no link e enviar tudo para o gateway padrão de qualquer maneira.
Aparentemente, o DNSMasq não configurado no link é um bug corrigido no 2.63, muito novo para o Debian 7. Precisa atualizar para o Debian 8 de qualquer maneira, fazendo isso hoje.
Editar, atualizar completo. A linha de configuração do DNSmasq foi alterada para:
Agora a rota para a sub-rede local é adicionada.