O que é CIDR?

O problema do modelo classful que CIDR veio resolver

No início dos anos 1980, o IPv4 usava um modelo de classes rígidas. O endereço IP dizia a qual classe pertencia pelos primeiros bits: classe A começava com 0 (blocos de 16 milhões de endereços), classe B com 10 (blocos de 65.534), classe C com 110 (blocos de 254 hosts). Não havia escolha intermediária. A tabela BGP global crescia com uma entrada por bloco classful, e o esgotamento dos blocos estava se acelerando.

Dois problemas concretos surgiram. O primeiro: desperdício brutal de endereços. Uma organização precisando de 500 hosts recebia um bloco Classe B com 65.534, desperdiçando mais de 99% dos endereços. O segundo: explosão da tabela de roteamento. Cada bloco Classe C adicionava uma entrada separada nos roteadores de backbone. Com milhares de redes novas por mês, os roteadores da época não tinham memória ou CPU suficientes para processar tabelas tão grandes.

O CIDR foi formalizado em 1993 pelas RFCs 1518 e 1519 e consolidado definitivamente pela RFC 4632 (2006, "Classless Inter-domain Routing: The Internet Address Assignment and Aggregation Plan"). A mudança fundamental foi simples: ao invés de determinar o tamanho do bloco pelo endereço, o tamanho passa a ser explícito no próprio prefixo.

Como ler a notação CIDR

A notação segue sempre o formato endereço/prefixo. O número após a barra indica quantos bits consecutivos, da esquerda para a direita, pertencem à parte de rede. Os bits restantes definem os hosts.

Leitura em IPv4 (32 bits no total)

No IPv4 o total de bits é 32. Com prefixo /24, a rede ocupa 24 bits e os hosts ocupam 8. A quantidade de endereços no bloco é sempre 2 elevado ao número de bits de host.

Cálculo rápido

Para descobrir o número de endereços de qualquer prefixo CIDR em IPv4: calcule 2 elevado a (32 menos o prefixo). Para /26: 2 elevado a 6, que dá 64 endereços totais. Descontando o endereço de rede (o primeiro) e o de broadcast (o último), sobram 62 hosts usáveis.

Tabela completa de prefixos CIDR para IPv4 (/8 a /32)

A tabela abaixo cobre os prefixos mais usados em projetos reais, do /8 ao /32, com máscara decimal equivalente e hosts usáveis. Os prefixos de /0 a /7 cobrem bilhões de endereços e são usados apenas em anúncios de rota padrão e sumários de backbone global.

CIDR no IPv6

O IPv6 nasceu já com notação CIDR. Não existiu era classful no IPv6. Com 128 bits de endereço, os prefixos usados na prática têm semântica muito diferente do IPv4.

Uma sub-rede /64 em IPv6 contém mais endereços do que átomos estima-se existirem na Terra. O planejamento de hosts dentro de um segmento /64 é irrelevante na prática: qualquer /64 é suficiente para qualquer rede local, independentemente do tamanho. O planejamento de subnetting em IPv6 foca em quantas sub-redes o site vai precisar, não em quantos hosts por sub-rede.

O prefixo 2804::/12 é o bloco LACNIC para IPv6. Todas as organizações brasileiras que recebem endereços IPv6 do LACNIC recebem sub-blocos dentro dessa faixa. A Vivo anuncia 2804:7f4::/32, a Claro usa 2804:14c::/32.

Conversão entre prefixo CIDR e máscara decimal

No IPv4, prefixo CIDR e máscara decimal são representações diferentes da mesma informação. Conversão manual: preencha os primeiros N bits com 1 e os restantes com 0 até completar 32 bits. Agrupe a cada 8 bits e converta para decimal.

A wildcard mask (máscara invertida) é usada em ACLs do Cisco IOS e no OSPF para definir o intervalo de endereços que uma regra cobre. O cálculo é simples: subtraia cada octeto da máscara decimal de 255. Para /27: 255-255=0, 255-255=0, 255-255=0, 255-224=31, resultando em 0.0.0.31.

Subnetting e supernetting na prática

Exemplo de subnetting: dividindo um /24 em quatro segmentos

Considere o bloco 192.168.10.0/24. Se você precisa de quatro segmentos iguais (servidores, desktops, Wi-Fi e IoT), divida em /26. Cada /26 tem 64 endereços e 62 hosts usáveis.

Supernetting: agregando rotas para reduzir a tabela BGP

O inverso também existe. Se você tem 192.168.10.0/24 e 192.168.11.0/24, pode anunciá-los como um único prefixo 192.168.10.0/23 no roteador de borda. Isso reduz a tabela de rotas do vizinho de 2 para 1 entrada. Funciona apenas quando os blocos são contíguos e alinhados binariamente. O bloco .10.0 e .11.0 se somam corretamente porque .10 em binário termina com 0 e .11 termina com 1, cobrindo o /23 inteiro.

Sumarizar blocos não contíguos ou mal alinhados cria rotas que cobrem endereços que não pertencem a você, gerando conflito de roteamento para outros sistemas autônomos.

CIDR e roteamento BGP global

O impacto mais duradouro do CIDR foi na tabela de roteamento global da internet, chamada DFZ (Default-Free Zone). Em 2005, quando a RFC 4632 foi publicada, a tabela BGP global tinha cerca de 160.000 prefixos. No início de 2026, segundo dados do APNIC Blog, a tabela IPv4 global ultrapassa 1,1 milhão de prefixos, com crescimento de cerca de 200 novas entradas por dia na segunda metade de 2025.

O CIDR é o que impede que esse número seja dez vezes maior. Sem sumarização de rotas, cada /24 de cada cliente de cada ISP estaria anunciado separadamente. Com CIDR, ISPs agregam os blocos de clientes antes de anunciar para o upstream: um único /16 representa até 256 redes /24 de clientes, mantendo a entrada na tabela global em 1 em vez de 256.

Prefixos de tamanho /24, /23 e /22 respondem por 84% da tabela IPv4 global no final de 2025 (fonte: APNIC Blog, BGP in 2025, jan/2026). A fragmentação da tabela aumenta o custo de operação dos roteadores de backbone, que precisam processar mais entradas para decidir o próximo salto de cada pacote.

Erros comuns ao trabalhar com CIDR

Mesmo administradores experientes cometem erros recorrentes. Os mais frequentes:

• Tratar /32 como rede multi-host. Um /32 é host route: um endereço único. Não tem broadcast nem network ID distintos. Usado em loopbacks e rotas estáticas para hosts específicos.
• Confundir subnetting com supernetting. Subnetting divide (prefixo aumenta de /24 para /26). Supernetting agrega (prefixo diminui de /24 para /23). A confusão gera ACLs e rotas erradas.
• Anunciar blocos mais específicos sem motivo técnico. Desagregar rotas no BGP polui a tabela global e pode violar a política do provedor upstream, resultando em filtragem do anúncio.
• Não alinhar blocos para sumarização. Dois /24 só se agregam em /23 se forem contíguos e o primeiro bloco terminar em zero binário. Os blocos .10.0 e .12.0 não formam um /23 válido juntos.
• Planejar sem margem de crescimento. Dimensionar para 100% de utilização imediata força reendereçamento quando a rede cresce. A prática padrão é planejar para no máximo 70-80% de ocupação.

Perguntas frequentes sobre CIDR