Esta não é uma resposta completa, já que eu ainda estou trabalhando com alguns dos problemas, mas aqui está o que eu tenho até agora, tentando implantar uma configuração quase idêntica (embora por razões um pouco diferentes). / p>
A boa notícia é: isso pode ser feito dentro das especificações. De fato, as especificações foram explicitamente projetadas para incentivar esse tipo de subdelegação de prefixos, em grande parte para evitar a necessidade de múltiplas camadas dolorosas de NAT, enquanto ainda permite flexibilidade na forma como as redes são estruturadas.
A má notícia é: não há softwares prontos para uso que solicitem um prefixo de upstream, configurem endereços e rotas localmente e distribuam sub-prefixos para redes downstream. Inferno, nem parece ser possível conectar partes de software pré-existentes no Linux (sem patch) para fazer o que precisa ser feito. Pior de tudo, não parece que alguém realmente se importe com isso.
O que eu tenho configurado e funcionando até agora é assim:
-
Estou usando o cliente WIDE DHCPv6 (
dhcp6c
) para solicitar um prefixo da rede "upstream"; Escolhi este cliente através do cliente DHCP do ISC porque, no momento em que o configurei, era o único cliente DHCPv6 que atribuía endereços automaticamente do prefixo recebido para outras interfaces. Eu gostaria de pensar que outros clientes DHCP melhoraram desde então, mas eu não poderia me incomodar em verificar neste momento.Infelizmente, não expõe os detalhes do prefixo delegado ao seu hook script externo, o que significa que você não pode (facilmente) reescrever sua configuração dhcpd "downstream".
-
Servidor ISC DHCP (no modo v6) para atribuir prefixos à rede "downstream". Escolhi isso porque o servidor DHCP do WIDE, até onde posso dizer, só pode delegar prefixos estaticamente, não dinamicamente. É relativamente fácil configurar o servidor ISC DHCP para fazer a delegação de prefixo dinâmico, surpreendentemente; algo tão simples como isso fará o truque:
subnet6 2001:db8:1234:ffff::/64 { prefix6 2001:db8:1234:a000:: 2001:db8:c0f:aff0:: /60; }
Isso escutará em qualquer interface que tenha um endereço em
2001:db8:1234:ffff::/64
e distribuirá / 60s do intervalo especificado. Contanto que você possa forçar odhcp6c
a atualizar a configuração acima (a seguir!), Você pode atualizar automaticamente a configuração do dhcpd quando o super-prefixo delegado for alterado. -
dhcp6c
irá, como mencionado anteriormente, obter um parâmetroscript
em seu arquivo de configuração, para ser executado quando uma resposta DHCPv6 for recebida. Infelizmente, ele apenas expõe parâmetros como o servidor SIP e resolvedores de DNS, e não informações úteis como o prefixo que foi delegado. Então, eu tenho o seguinte scriptlet para fazer isso por mim:#!/bin/sh (sleep 3; base_prefix="$(ip -6 ad sh eth0 | grep 'scope global' | cut -d ' ' -f 6 | cut -d : -f 1-4 | sed 's/00$//')" if [ "$base_prefix" = "" ]; then exit 0 fi cat <<-EOF >/etc/dhcp/dhcpd6.conf default-lease-time 1800; max-lease-time 7200; subnet6 ${base_prefix}00::/64 { prefix6 ${base_prefix}a0:: ${base_prefix}f0:: /60; } EOF svc -t /etc/service/dhcp6d) & exit 0
Fazer todo o trabalho em um sub-shell significa que eu posso esperar um pouco (o
sleep 3
) pelo cliente DHCP para realmente configurar a interface (parece que o script é executado antes configurar a interface). Ele funciona de forma confiável o suficiente. Note que o meu ISP me delega um/56
, por isso estou apenas removendo os dois zeros do prefixo recebido. Se você tiver a sorte de obter todo o/48
, o canal para atribuirbase_prefix
seria muito mais simples.
O que não já existe, e estou certo de que requer a correção do código-fonte, está configurando rotas quando um prefixo é delegado. Tanto quanto eu posso ver, nenhum servidor DHCP tem a capacidade interna para adicionar a rota automaticamente (eu examinei cuidadosamente% WIDE dhcp6s
, certamente não pode fazê-lo, e não consigo encontrar nada sobre o ' tubos para sugerir que ISC DHCP faz isso). Não há nem mesmo a capacidade de executar um comando externo que recebe o prefixo que está sendo delegado e o endereço local do link do cliente (o ISC DHCP tem on commit { execute(...) }
, mas nenhuma maneira de desmaiar o endereço do link do cliente). / p>
O problema é que, sem esse bit crucial de funcionalidade, o roteador que está fazendo a delegação não pode saber para onde encaminhar o tráfego para o prefixo depois. Essa é uma limitação bastante fundamental, e eu estou um tanto chocado que ninguém parece ter lidado com esse problema antes - ou se eles tiverem, eles estão realmente em silêncio sobre isso.
Acabei de desenvolver um patch para o ISC DHCP para fornecer uma "expressão de dados" extra para a funcionalidade eval; isto permite-me desembolsar para um programa externo que pode então adicionar / remover rotas na alocação de prefixo e liberação / expiração; o patch está disponível no link (contra o ISC DHCP 4.3.1); Eu não tenho um script para adicionar a rota (ainda), mas provavelmente vou adicioná-la em contrib
nessa ramificação depois que eu a escrever.
ADENDO: Acontece que mais modificações foram necessárias para permitir que as rotas fossem removidas novamente; que agora foi adicionado à ramificação client-address-data-expression
, juntamente com um pequeno script Ruby que mostra como tudo pode ser combinado.