Eu notei um problema de roteamento com o IPv6 com a nossa LAN. A maioria dos PCs clientes são thin clients LTSP. Eles recebem um endereço através do SLAAC. Tracepath6 para 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 dois endereços IPv6 e configura rotas que o tráfego all acessa primeiro o roteador, incluindo o tráfego no mesmo 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 recebem um e alguns hosts mais endereços? Eu vejo isso acontecer com mais frequência.
2) Por que esta máquina está escolhendo encaminhar todo o tráfego através do roteador?
O roteador é dnsmasq e, na verdade, só possui o 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
Esta é a minha 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 do 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 do 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 seguinte linha não está presente em hosts que alcançam outros hosts diretamente:
::/0 fe80::213:3bff:fe0f:c02c UG 1 2 0 eth0
fe80::213:3bff:fe0f:c02c , de fato, é o endereço de link local do roteador, no lado da LAN.
Editar: o comportamento que tenho visto pode ser aleatório. Eu 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 de quase todos os reinícios, parece. A tabela de roteamento é exatamente a mesma a cada vez, 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, deve enviar apenas a eth0, por exemplo. Então, quando eu adiciono esta 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::/64 não é incluído por padrão (em qualquer máquina aqui)? Uma rota não deveria estar presente, informando ao kernel que, para a sub-rede atual, basta enviar pela Ethernet (ou wlan, seja qual for)?
Edit3: Acabei de olhar com tcpdump + wireshark e vi que o sinalizador L , On-Link, não está definido no anúncio do roteador, apesar de o off-link não estar definido:
dhcp-range=xxxx:1b0:5256:1337::, ra-only, inifite
Aparentemente, DNSMasq não configurando on-link é um bug que foi corrigido em 2.63, simplesmente muito novo para o Debian 7. Precisa atualizar para o Debian 8 mesmo assim, fazendo isso hoje.
Editar, atualizar completo. A linha de configuração DNSmasq foi alterada para:
dhcp-range=::,ra-only,constructor:eth1,infinite
Agora, a rota da sub-rede local é adicionada.
1) Why do some hosts get one and some hosts more addresses? I've see this happen more often.
Os hosts IPv6 sempre obtêm um endereço de link local. Os outros endereços dependem de uma combinação dos sinalizadores nas configurações RA e host. O RA pode sinalizar ao host que um servidor DHCPv6 pode distribuir endereços, nos quais o host pode atuar. Se o RA contiver prefixos que permitam 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 (normalmente o endereço MAC). Mas seria possível rastrear dispositivos pela Internet. Imagine um serviço frequentemente contatado do Google ou do Dropbox: para qualquer rede que você conecte seu laptop ou celular, a sub-rede mudará, mas o ID da interface será sempre o mesmo. Portanto, os sistemas operacionais fornecem extensões de privacidade nos dias de hoje.
As extensões de privacidade fazem seu ID de interface mudar regularmente. Os cronômetros exatos dependem da implementação, mas vamos supor que isso mude a cada hora. A cada hora, o dispositivo configura um novo endereço IPv6 para si mesmo. Os endereços antigos são obsoletos e, depois que o software pára 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, seu dispositivo configurará endereços em cada um deles.
2) Why is this machine choosing to route all traffic through the router?
Isso geralmente depende do sinalizador On-Link nos prefixos no RA. Se o sinalizador no link estiver definido, o dispositivo poderá criar uma rota para o /64 na 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 envia todos esses pacotes para o gateway padrão.
É claro que seu dispositivo sempre pode escolher (intencionalmente ou por causa de um bug) para ignorar o sinalizador no link e enviar tudo para o gateway padrão de qualquer maneira.