IPv6
Plano de endereçamento IPv6 para provedores: como dividir o /32
Como dividir o bloco IPv6 de um provedor: limites de nibble, infraestrutura, loopbacks, links /127, clientes residenciais com /56 por DHCPv6-PD, corporativos com /48 e prefixo fixo.
Por Rodrigo Borges, BTECH Automations · · 10 min de leitura
Ativar IPv6 em um provedor leva uma tarde. Refazer um plano de endereçamento IPv6 mal feito, com clientes já usando, leva meses: muda prefixo de cliente, muda filtro, muda rota, muda reverso. A diferença está no que foi decidido antes de configurar o primeiro equipamento.
Neste tutorial você vai ver como dividir o bloco IPv6 de um provedor, quanto entregar a cada tipo de cliente, como fica a infraestrutura e os clientes PPPoE, e os erros que mais obrigam provedores a recomeçar.
Por que planejar antes de configurar
No IPv4, a escassez obrigava a economizar cada endereço, e o plano era quase sempre "o que sobrou". No IPv6 o problema se inverte: há espaço de sobra, e o risco é distribuí-lo sem estrutura. Um bom plano:
- agrega rotas: cada POP ou concentrador anuncia um único prefixo para o backbone, em vez de centenas;
- é legível: só de olhar um endereço, a equipe sabe se é infraestrutura, cliente corporativo ou residencial, e de qual POP;
- tem espaço para crescer: um POP novo ou um concentrador a mais encaixam sem renumerar nada;
- facilita filtros e reverso: regras de firewall, ROAs e zonas reversas seguem a mesma estrutura.
Limites de nibble
Cada dígito hexadecimal de um endereço IPv6 representa 4 bits, um nibble. Dividir o bloco sempre em múltiplos de 4 bits (/32, /36, /40, /44, /48...) faz cada nível da hierarquia corresponder a um dígito do endereço:
| Prefixo | Dígito que muda | Quantidade dentro do /32 |
|---|---|---|
| /36 | 2001:db8:X000:: | 16 |
| /40 | 2001:db8:XX00:: | 256 |
| /44 | 2001:db8:XXX0:: | 4.096 |
| /48 | 2001:db8:XXXX:: | 65.536 |
Com limites de nibble, 2001:db8:2a00::/40 é imediatamente reconhecível. Com um /38 ou /42, o limite cai no meio de um dígito, e a equipe precisa de calculadora para saber onde cada bloco começa e termina. As zonas de DNS reverso, que são divididas por nibble, também ficam mais simples.
Quanto entregar a cada cliente
| Tipo de cliente | Prefixo recomendado | Redes /64 disponíveis |
|---|---|---|
| Residencial | /56 | 256 |
| Pequena empresa | /56 ou /48 | 256 ou 65.536 |
| Corporativo | /48 | 65.536 |
A tentação é economizar entregando um /64 ao residencial, "porque é o que ele usa". Só que um /64 é uma única rede: o cliente não consegue separar convidados, câmeras e dispositivos de IoT, e roteadores que criam sub-redes automaticamente deixam de funcionar direito. Um /32 tem mais de 16 milhões de /56; economia aqui não se justifica.
Um exemplo de divisão do /32
Uma estrutura comum é usar o primeiro nível (/36) para separar funções e os níveis seguintes para separar POPs e concentradores. Com o bloco de documentação 2001:db8::/32:
2001:db8::/32 bloco do provedor
├─ 2001:db8:0000::/36 infraestrutura e serviços
│ ├─ 2001:db8:0000::/48 loopbacks
│ ├─ 2001:db8:0001::/48 enlaces entre roteadores
│ └─ 2001:db8:0010::/44 servidores (DNS, RADIUS, sistemas)
├─ 2001:db8:1000::/36 clientes corporativos, /48 cada (4.096)
├─ 2001:db8:2000::/36 residencial, POP 1
│ ├─ 2001:db8:2000::/40 concentrador 1, /56 cada (65.536)
│ └─ 2001:db8:2100::/40 concentrador 2
├─ 2001:db8:3000::/36 residencial, POP 2
└─ 2001:db8:4000::/36 a f000 reserva para crescimento
Esse é só um formato possível. O plano certo depende de quantos POPs e concentradores existem e vão existir, de quantos clientes cada um atende, de como o backbone agrega rotas e de como a rede deve estar daqui a cinco anos. Com o endereçamento já em uso, cada decisão errada aqui custa uma renumeração.
Infraestrutura: loopbacks e enlaces
- Loopbacks: um /128 por roteador, todos tirados de um mesmo bloco. Facilita filtros de acesso à gerência e a identificação nos logs.
- Enlaces entre roteadores: reserve um /64 por enlace no plano e configure um /127 dentro dele, como recomenda o RFC 6164. O /64 inteiro configurado permite ataques de exaustão da tabela de vizinhos.
- Endereços legíveis: usar parte do endereço para identificar o equipamento ou o enlace ajuda muito no diagnóstico, desde que siga uma regra documentada.
- ICMPv6 liberado: no IPv6, a descoberta de vizinhos e o ajuste de MTU dependem do ICMPv6. Bloquear tudo, como muitos fazem no IPv4, quebra a rede de formas difíceis de diagnosticar.
Clientes PPPoE: enlace e prefixo delegado
Em provedores com PPPoE, cada cliente normalmente recebe dois prefixos diferentes:
- Prefixo do enlace (WAN): um /64 anunciado pelo concentrador, usado pelo roteador do cliente para ter um endereço na interface WAN.
- Prefixo delegado (LAN): o /56 entregue por DHCPv6-PD, que o roteador do cliente divide em redes /64 para a rede interna.
Os dois devem vir de faixas separadas no plano, cada uma agregada por concentrador. Misturar os dois na mesma faixa, ou espalhar faixas de um mesmo concentrador pelo bloco, faz o backbone carregar milhares de rotas que poderiam ser uma só.
O RADIUS pode entregar o prefixo delegado (atributo Delegated-IPv6-Prefix) ou indicar de qual pool ele sai. A escolha entre um e outro está ligada à próxima decisão.
Prefixo fixo ou dinâmico
No IPv4 com CGNAT, mudar o IP do cliente a cada reconexão não afeta quase ninguém. No IPv6, o prefixo é usado diretamente pelos dispositivos da casa, e trocá-lo a cada reconexão:
- quebra regras de firewall e liberações que o cliente configurou;
- deixa dispositivos com endereços antigos por algum tempo, até perceberem a mudança;
- complica a identificação do cliente em ofícios e no reverso.
A recomendação é o prefixo estável: o mesmo cliente recebe sempre o mesmo /56. Isso exige que a atribuição seja controlada (pelo RADIUS, pelo sistema de gestão ou pelo IPAM) e não sorteada pelo concentrador a cada conexão, e tem impacto em migração de clientes entre concentradores.
Erros que obrigam a refazer o plano
- /64 para residencial. Funciona até o primeiro cliente precisar de duas redes.
- Divisões fora do nibble. Tornam o plano ilegível e as zonas reversas mais complicadas.
- Sem reserva para crescimento. O POP novo não cabe na estrutura, e a hierarquia é quebrada logo no primeiro ano.
- Faixas de um concentrador espalhadas. O backbone perde a agregação.
- Prefixo dinâmico. Gera reclamação e é difícil de mudar depois que os clientes já estão usando.
- Esquecer o resto. Objetos
route6no IRR, ROAs, reverso, filtros de anti-spoofing e o monitoramento precisam acompanhar o plano.
Do tutorial à produção
Os princípios cabem em uma página. Levar o IPv6 a todos os clientes, com um plano que dure, envolve a rede inteira, e é isso que fica fora deste tutorial:
- Plano para a sua rede. Hierarquia desenhada para os seus POPs, concentradores e crescimento, documentada no IPAM (como o NetBox).
- Concentradores e RADIUS. PPPoE ou IPoE com DHCPv6-PD, prefixo estável por cliente e pools agregados.
- Backbone e bordas. Roteamento interno, anúncio do bloco, filtros e anti-spoofing em IPv6.
- Registros. Route6 no IRR, ROAs, reverso DNS e identificação do cliente pelo prefixo.
- Migração sem interrupção. Ativação gradual, testes com grupos de clientes e acompanhamento do suporte.
Perguntas frequentes
Qual prefixo IPv6 entregar ao cliente residencial?
Um /56 é a recomendação mais adotada: permite 256 redes /64 dentro da casa, para separar rede de convidados, câmeras e dispositivos de IoT. Entregar só um /64 impede o cliente de criar sub-redes e é considerado má prática.
Por que usar /127 em enlaces ponto a ponto?
O RFC 6164 recomenda /127 em enlaces entre roteadores para evitar ataques de exaustão da tabela de vizinhos, que são possíveis com um /64 configurado. A prática comum é reservar um /64 inteiro para cada enlace no plano e configurar só o /127 dentro dele.
Um /32 é suficiente para um provedor?
Para a grande maioria, sim. Um /32 tem 16,7 milhões de prefixos /56, ou 65.536 prefixos /48. Provedores grandes, com muitos POPs ou que precisam de mais níveis de hierarquia, podem justificar um bloco maior junto ao NIC.br.
O cliente precisa trocar o roteador para ter IPv6?
Depende do equipamento. O roteador do cliente precisa suportar IPv6 na WAN e DHCPv6-PD para receber o prefixo delegado e distribuir na rede interna. Boa parte dos roteadores atuais suporta, mas modelos antigos ou com firmware desatualizado podem não suportar.
CONSULTORIA BTECH
Prefere que alguém faça isso por você?
A BTECH Automations é uma consultoria em automação, redes e cloud para provedores, operadoras e empresas de hospedagem. Implementamos IPv6 para provedores de ponta a ponta, documentamos e mantemos funcionando, com um pacote mensal de horas e relatório de cada atividade.
- ✓ Filtros BGP, IRR, RPKI e DNS automatizados
- ✓ Zabbix, Grafana, logs e alertas sob medida
- ✓ Cloud, virtualização, backups e portais do cliente