The issue I have is that the DSL router is sending neighbor solicitations packets on eth1 when it gets inbound packets from the internet, and those neighbor solicitations are not being passed from eth1 -> eth0 on the Linux router.
Isso é normal. As solicitações vizinhas funcionam como as consultas ARP - elas convertem um endereço IP em um endereço MAC e, portanto, só fazem sentido dentro do mesmo domínio de transmissão. Não faz sentido que um roteador os encaminhe.
(Embora em algumas situações um roteador possa proxy eles, como descrito no final, mas ... deixe isso para o plano C.)
I am thinking that this is occurring because the DSL router thinks it is directly connected to the home network (which is how it would normally be in 99% of home networks without a Linux router in the middle).
Sim, e você nunca contou de outra forma.
Assim, sua situação atual é que a mesma sub-rede IP está sendo usada por duas redes diferentes, e você espera que o roteador Linux funcione como uma ponte ... O que é quase o oposto de um roteador.
(Se a parte confusa for IPv6, pense em toda a configuração em termos IPv4, pois o roteamento é mais ou menos o mesmo em ambos, e o ND é equivalente em grande parte ao ARP. Portanto, se você não usasse o mesmo 192.168. Sub-rede 1.0 na v4 ...)
Seu melhor curso de ação é obter um segundo / 64, e usar esse para a rede eth1 do seu roteador Linux. (Se o roteador DSL obtiver seu prefixo via DHCPv6-PD, pode ser possível enganá-lo ao solicitar um segundo.) A diferença é que o segundo / 64 não seria usado diretamente em uma interface, mas encaminhado para o endereço do router Linux.
Por exemplo:
- O roteador DSL tem 2001: db8: 0: 0: a: b: c: d na interface WAN.
- O roteador DSL obtém 2001: db8: 10: 0 :: / 64 do ISP, atribui-se a si próprio 2001: db8: 10: 0 :: 1/64 na interface da LAN e envia anúncios de roteador para ele.
- Autoconfigurações do roteador Linux 2001: db8: 10: 0: x: y: z: t na eth1 com base em RAs.
- O roteador Linux obtém 2001: db8: 10: 1 :: / 64 do ISP (de alguma forma), atribui a si próprio 2001: db8: 10: 1 :: 1/64 na interface eth0 e radvd envia anúncios de roteador para que - não para a primeira sub-rede.
- O roteador DSL precisa de uma rota como "2001: db8: 10: 1 :: / 64 via 2001: db8: 10: 0: x: y: z: t" para que todo o tráfego da segunda sub-rede seja encaminhado para o roteador Linux.
(Desculpas pelo exemplo não muito claro)
Às vezes, o ISP delega um todo / 60 ou até mesmo / 56 para você e o encaminha para o roteador DSL. Nesse caso, você poderia simplesmente configurar a segunda sub-rede sem qualquer mágica de DHCPV6-PD. Realmente, embora eu não possa fornecer uma boa resposta "genérica" aqui, pois é dependente do ISP e do CPE.
Se a obtenção de um segundo prefixo / 64 for impossível, outras opções possíveis são:
-
Transforme o sistema Linux em uma ponte pura, sem qualquer funcionalidade de roteamento.
-
Use outras fontes para obter / 64s adicionais, como um provedor de encapsulamento (ou 6to4). Os serviços de encapsulamento existentes funcionarão de forma muito mais confiável (exceto por alguma latência extra) do que os hacks descritos abaixo.
-
Faça o roteador DSL obter apenas o / 64, mas não configure-o para a LAN. (Depende de quão flexível é o roteador.) Em vez disso, configure novamente uma rota para esse / 64 através do endereço eth0 link-local do seu sistema Linux e, da mesma forma, configure uma rota no sistema Linux para :: / 0 através do roteador DSL. Endereço de ligação local da LAN. Como resultado, o / 64 será usado apenas na segunda sub-rede, e o primeiro não terá nenhum prefixo público.
-
Continue com sua configuração atual, mas instale o 'ndppd' para executar o proxy da detecção de vizinho. (Não, o encaminhamento multicast não fará como os pacotes ND geralmente têm endereços de origem local de link.) Tenha cuidado com isso, isso pode tornar as coisas realmente confusas.
-
Use endereços privados (ULA) para a 2ª LAN e ative o NAT de 1 para muitos (masquerading) no roteador Linux ... perdendo a maior parte da utilidade do IPv6 no processo. (Sim, oficialmente o NAT não existe no IPv6, mas isso não impediu que o netfilter / iptables do Linux cedesse e implementasse).