A (RFC) 4291 divide o endereço IPv6 global unicast em três partes: o prefixo de roteamento global do site, o identificador (ID) de sub-rede, que nomeia um enlace, e o ID de interface; fora do bloco binário 000, as duas primeiras somam 64 bits (RFC 4291, seção 2.5.4). Com a metade de baixo ocupada, fazer sub-redes no IPv6 é repartir a de cima: a Internet Assigned Numbers Authority () abastece os Regional Internet Registries (RIRs), que alocam para os Local Internet Registries (LIRs) e os Internet Service Providers (ISPs), os provedores atribuem prefixos aos sites, e cada site dá um /64 a cada enlace. Como funciona o endereçamento IPv6 cobre o formato. Ao final, você consegue dimensionar cada nível, explicar por que a Stateless Address Autoconfiguration () prende o enlace em /64 e conferir um plano em Python, no iproute2 e numa captura.

Do registro ao enlace

A RFC 3587 deixa o prefixo de roteamento com os RIRs e os ISPs, e "The subnet field is designed to be structured hierarchically by site administrators", a sub-rede é do administrador (RFC 3587, seção 3). A IANA pode alocar o 2000::/3 aos RIRs (ripe-738, seção 1.1); em 3 de outubro de 2006 cada um dos cinco recebeu um /12, e o 2800::/12 coube ao Latin American and Caribbean Internet Address Registry (), que atende o Brasil (registro unicast da IANA); um /12 contém 2^20 = 1.048.576 prefixos /32. O RIPE Network Coordination Centre (RIPE NCC) dá a um LIR habilitado de um /32 a um /29 sem outra justificativa (ripe-738, seções 4.3 e 5.1.2) e deixa o tamanho do site com o LIR ou o (seção 5.4.1); o LACNIC recomenda um /48 por site (LACNIC Policy Manual, seção 4.4.3.1). Daí para baixo, vale a aritmética Classless Inter-Domain Routing () do IPv4 (RFC 4291, seção 2.5), como em Como funciona a notação CIDR.

Por que o enlace é um /64

O 64 é do ID de interface: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long", 64 bits fora do bloco 000 (RFC 7136, seção 5). A SLAAC deixa esse tamanho para o documento de cada tipo de enlace (RFC 4862, seção 2), e o da diz: "An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an Ethernet interface must have a length of 64 bits", prefixo de 64 bits (RFC 2464, seção 4). Uma soma decide: "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored", sem somar 128, é ignorada (RFC 4862, seção 5.5.3). Um /80 mais 64 dá 144, e nenhum endereço sai dali; como um host monta o endereço mostra o resto.

O Neighbor Discovery não precisa do /64. A RFC 7421 viu que a flag A, que permite a configuração sem estado, só vale com tamanho 64, enquanto a flag L, que marca o prefixo como on-link, "is honored for any arbitrary prefix length (whether shorter or longer than /64)", vale com qualquer tamanho (RFC 7421, seção 4.3.1). O /64 também não é regra de encaminhamento: "In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1", qualquer tamanho até /128 (RFC 7608, seção 2). Ele substituiu o /80 previsto em dezembro de 1998, em parte por se esperar que endereços Media Access Control (MAC) de 64 bits, os Extended Unique Identifier (), se espalhassem (RFC 7421, seção 1; RFC 2464, seção 8), e encerra o hábito do variable-length subnet masking (VLSM) de dimensionar sub-redes pelos hosts (RFC 7421, seção 2).

O tamanho do prefixo de um site

Em 2001, a RFC 3177 recomendava /48 no caso geral, /64 para uma única sub-rede e /128 para um único dispositivo (RFC 3177, resumo). Em 2011, a RFC 6177 disse que o /48 igual para todos "is no longer recommended as a single default", deixou de ser o padrão único (RFC 6177, resumo), sem fixar tamanho, mas pedindo para residências bem mais que um /64, como um /56 (seções 1 e 2). Em 2017, o ripe-690 desaconselhou com força prefixos mais longos que /56 e propôs um /48 por usuário final ou a divisão "by offering /48 for business customers and /56 for residential customers", empresas com /48, residências com /56 (ripe-690, seção 1). Um /32 contém 16.777.216 prefixos /56 (seção 4.2.3), e a RFC 7421 não vê risco objetivo de esgotamento nem para os menores sites (RFC 7421, seção 3.1).

A entrega pode ser a delegação de prefixo do Dynamic Host Configuration Protocol for IPv6 (), especificada desde janeiro de 2026 pela RFC 9915, o Internet Standard 102, que torna obsoleta a RFC 8415, e é "appropriate for use by an ISP to delegate a prefix to a subscriber", do provedor para o assinante (RFC 9915, seção 6.3), cujo roteador pode então atribuir sub-redes do prefixo aos enlaces (seção 6.3). A RFC 7084 manda o roteador de borda do cliente pedir o bastante para um /64 por interface, arredondado ao nibble, e ele "MUST assign a separate /64 from its delegated prefix(es)", um /64 próprio, a cada interface de rede local () (RFC 7084, seções 4.2 e 4.3).

A conta do ID de sub-rede

Um /n contém 2^(m-n) prefixos de tamanho /m, e o ID de sub-rede fica entre o prefixo do site e o /64:

Prefixo do siteBits do IDDígitos hexadecimaisSub-redes /64
/4816465.536
/521234.096
/5682256
/604116

Um /64 contém 2^64 = 18.446.744.073.709.551.616 endereços, exatamente o total do IPv4 ao quadrado, não mais: um endereço IPv4 tem 32 bits, que ocupam os 32 bits de baixo quando o IPv6 embute um (RFC 4291, seção 2.5.5), e 4.294.967.296 × 4.294.967.296 = 2^32 × 2^32 = 2^64. No prefixo de documentação 2001:db8::/32 (RFC 3849, resumo), o 2001:db8:abcd::/48 numera seus /64 no quarto grupo, de 2001:db8:abcd::/64 a 2001:db8:abcd:ffff::/64. O /56 2001:db8:abcd:1a00::/56 fixa dois desses dígitos (1a00 a 1aff), o /60 2001:db8:abcd:1a30::/60, três (1a30 a 1a3f), e um /62 como 2001:db8:abcd:1a34::/62 (1a34 a 1a37) termina no meio de um dígito.

Fronteiras de nibble e DNS reverso

Os planos andam um nibble, um dígito hexadecimal, por vez: "The length of a delegated prefix should therefore always be a multiple of 4", múltiplo de 4 (ripe-690, seção 4.2), e o American Registry for Internet Numbers (ARIN) faz todas as alocações em fronteiras de nibble (política do ARIN, seção 6.5.2.1). O DNS reverso é a segunda razão. Um nome ip6.arpa lista os nibbles do endereço em ordem inversa, um por rótulo (RFC 3596, seção 2.5), então um /n alinhado em nibble é uma zona de n/4 rótulos: 2001:db8:abcd::/48 é d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa. Um /50 como 2001:db8:abcd:4000::/50 são quatro zonas, de 4.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa a 7.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa, e o LIR tem de delegar todas quando pedido (ripe-738, seção 5.6); Consultas DNS reversas com o nslookup trata das consultas. Dentro do site, numere as sub-redes de forma compacta, pelos bits de baixo, como se só houvesse um /56 mesmo num /48 (RFC 5375, seção 2.4).

Enlaces entre roteadores e loopbacks: /127 e /128

Entre roteadores, a RFC 6164 considera úteis os prefixos de 127 bits, e "Such a practice parallels the use of 31-bit prefixes in IPv4", como o /31 do IPv4 (RFC 6164, resumo). Ali, um prefixo mais curto pode criar um loop de encaminhamento, e um ataque ao cache de vizinhos de um /64 pode impedir que sessões se restabeleçam, pois os roteadores deixam de resolver os endereços um do outro; o /127 elimina isso (seções 5.1 e 5.2). A seção 6 determina: "Routers MUST support the assignment of /127 prefixes on point-to-point inter-router links. Routers MUST disable Subnet-Router anycast for the prefix when /127 prefixes are used", suportar /127, sem anycast. O Subnet-Router é o endereço anycast com o ID de interface todo em zeros (RFC 4291, seção 2.6.1).

A RFC 6164 também tira desses enlaces os IDs de interface todos em zero e os 128 valores mais altos, reservados ao anycast de sub-rede (RFC 6164, seção 6). Ela imprime a faixa a partir de ff7f, e a errata 3422 corrige: "The highest 128 values start at ffff:ffff:ffff:ff80, not ffff:ffff:ffff:ff7f", começam em ff80 (RFC 6164, errata 3422); este texto segue a errata. Então reserve um /64 por enlace e use um /127 dele que evite as duas faixas (ripe-690, seção 1): não o primeiro /127 de 2001:db8:0:ff::/64, que contém o 2001:db8:0:ff:: todo em zeros.

O apêndice B.2.2 da RFC 5375 chamava o /127 de inválido até a errata 3309, verificada em 2012, fazê-lo dizer que o /127 "is valid as stated in RFC 6164 [RFC 6164]", é válido (RFC 5375, errata 3309); este texto segue a errata. Loopbacks usam um /128, para quando um endereço basta (RFC 5375, apêndice B.2.3), como 2001:db8:0:ffff::1/128.

Prefixos locais únicos

Os Unique Local Addresses (ULAs) fazem o papel do espaço de endereços IPv4 privados, mas são feitos para ser únicos: fc00::/7, um bit L em 1 para atribuição local, o que torna fd o primeiro byte, um ID global de 40 bits, um ID de sub-rede de 16 bits e o ID de interface (RFC 4193, seção 3.1). O ID global tem de ser aleatório: "They MUST NOT be assigned sequentially or with well-known numbers", nem sequenciais nem conhecidos (seção 3.2), o que descarta o fd00::/48. O hash da hora 2026-10-18T00:00:00Z com o EUI-64 34-56-78-FF-FE-9A-BC-DE, tirado do MAC de exemplo da RFC 2464, reduzido aos 40 bits menos significativos (seção 3.2.2), dá o prefixo ilustrativo fd6c:f4fb:acc3::/48. Reaproveite os IDs de sub-rede do plano global, filtre os ULAs nos dois sentidos, por padrão, numa borda BGP (seção 4.1) e deixe os registros deles fora do DNS global (seção 4.4). ULA não implica (RFC 5375, seção 2.2).

Erros que quebram um plano

Primeiro, um prefixo mais longo que /64 onde há hosts. A RFC 5375 diz que usá-lo "for links containing end hosts would be an especially bad idea", uma ideia especialmente ruim (RFC 5375, seção 3). Esses enlaces perdem a SLAAC, e um /120 deixa um identificador de 8 bits, com colisões altamente prováveis (RFC 7421, seções 4.4 e 4.2).

Segundo, economizar como no IPv4: "Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs", quebra a rede do cliente (ripe-690, seção 4.2.3). Uma casa que recebe um /60 e dá um /64 a cada dispositivo fica sem prefixos depois de 15 deles (RFC 9762, seção 1).

Terceiro, um plano que não sumariza; decide o alinhamento, não a contagem. Dezesseis /48 de 2001:db8:a0::/48 a 2001:db8:af::/48 viram 2001:db8:a0::/44, mas dezesseis de 2001:db8:a8::/48 a 2001:db8:b7::/48 exigem 2001:db8:a8::/45 e 2001:db8:b0::/45, e /48 ULA aleatórios nunca se agregam (RFC 5375, seção 2.4); veja Sumarização de rotas e supernetting.

Quarto, o /64 esparso, "a number so large it covers literally billions of billions of addresses, the overwhelming majority of which will be unassigned", quase todos sem uso (RFC 6583, seção 2), que um ataque ao cache de vizinhos do roteador explora. Dimensionar a sub-rede pelos endereços em uso evita o problema, mas exclui a SLAAC e só serve a hosts configurados estaticamente (seção 6.2); limitar o tamanho do cache e as entradas incompletas também derrota o ataque (RFC 7421, seção 3.4).

Como ver na prática

O Kit de ferramentas IPv6 lê um prefixo por vez: para 2001:db8:abcd:1a00::/56, mostra a rede, o primeiro e o último endereço, a contagem (2^72, com o decimal exato) e os bits de host. Não lista sub-redes; sua linha ip6.arpa é o nome do endereço digitado, então use os últimos n/4 rótulos como zona; sua tabela de usos especiais não tem o 3fff::/20, o segundo bloco de documentação (RFC 9637, seção 6), e mostra 3fff:: como global unicast; e sua linha EUI-64 recupera o MAC de um ID de interface EUI-64 modificado, sem montar um. O Playground de Python roda o ipaddress do CPython 3.14 para o resto, e o exemplo ipv6-eui64 monta 21a:2bff:fe3c:4d5e do MAC 00:1A:2B:3C:4D:5E.

Uma sessão ilustrativa, em Python 3.13 com chamadas documentadas para o 3.14 (documentação do ipaddress):

>>> import ipaddress
>>> site = ipaddress.ip_network("2001:db8:abcd::/48")
>>> site.num_addresses
1208925819614629174706176
>>> 2 ** (64 - site.prefixlen)
65536
>>> list(site.subnets(new_prefix=52))[:3]
[IPv6Network('2001:db8:abcd::/52'), IPv6Network('2001:db8:abcd:1000::/52'), IPv6Network('2001:db8:abcd:2000::/52')]
>>> home = ipaddress.ip_network("2001:db8:abcd:1a00::/56")
>>> lans = list(home.subnets(new_prefix=64))
>>> len(lans)
256
>>> lans[0], lans[1], lans[-1]
(IPv6Network('2001:db8:abcd:1a00::/64'), IPv6Network('2001:db8:abcd:1a01::/64'), IPv6Network('2001:db8:abcd:1aff::/64'))
>>> home.network_address.reverse_pointer
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa'
>>> list(ipaddress.ip_network("2001:db8:0:ff::/127").hosts())
[IPv6Address('2001:db8:0:ff::'), IPv6Address('2001:db8:0:ff::1')]
>>> ipaddress.ip_network("2001:db8:abcd:12::1/64")
Traceback (most recent call last):
  ...
ValueError: 2001:db8:abcd:12::1/64 has host bits set

hosts() omite o anycast Subnet-Router, exceto em /127, daí os dois endereços acima, embora a RFC 6164 tire o primeiro de um enlace entre roteadores; a zona do /56 são os últimos 14 rótulos de reverse_pointer; e o modo estrito recusa bits de host (mesma documentação).

No Linux, com a sintaxe dos manuais do iproute2:

ip -6 address show dev eth0
ip address add 2001:0db8:85a3::0370:7334/64 dev eth1
ip -6 route show

-6 é atalho para -family inet6 (ip(8)); /127 e /128 se escrevem como o /64, mas o mngtmpaddr, usado pelos endereços de privacidade, exige tamanho 64 (ip-address(8)); e rotas com protocolo ra vieram do Router Discovery (ip-route(8)).

Um Router Advertisement é o tipo 134 do Internet Control Message Protocol for IPv6 () (RFC 4861, seção 4.2). Sua opção Prefix Information traz Type 3, Length 4 (unidades de 8 octetos), Prefix Length (0 a 128), as flags L, A, R e P, dois tempos de vida, um campo reservado e o prefixo de 128 bits (seção 4.6.2; RFC 9762, seção 5), e a P indica que a rede prefere delegação de prefixo a endereços por SLAAC ou DHCPv6 (RFC 9762, seção 5). Uma delegação é uma OPTION_IA_PD (25) com opções OPTION_IAPREFIX (26), cada uma com dois tempos de vida, um tamanho de prefixo de 1 octeto e o prefixo de 16 octetos (RFC 9915, seções 21.21 e 21.22). Filtros de exibição do Wireshark para os dois:

icmpv6.type == 134 && icmpv6.opt.prefix.length != 64
dhcpv6.iaprefix.pref_len

O primeiro pega anúncios sem nenhum /64, porque != num campo repetido exige todas as ocorrências diferentes (wireshark-filter(4)); o segundo lista os tamanhos delegados (referência DHCPv6 do Wireshark). As flags são icmpv6.opt.prefix.flag.l, .flag.a e, a partir do Wireshark 4.6.0, .flag.p (referência ICMPv6 do Wireshark).

Para lembrar

  • A SLAAC ignora o prefixo que, com o ID de interface de 64 bits, não soma 128, então enlaces com hosts são /64; Neighbor Discovery e encaminhamento aceitam qualquer tamanho.
  • Um RIR tem /12, um LIR pelo menos um /32, um site um /48 ou /56, que o DHCPv6 pode delegar, e cada enlace um /64.
  • Um /n contém 2^(m-n) prefixos de tamanho /m, 65.536 /64 num /48, e os 2^64 endereços de um /64 são exatamente o total do IPv4 ao quadrado.
  • Passos de nibble põem cada fronteira num dígito hexadecimal e num rótulo ip6.arpa; um /50 exige quatro zonas reversas.
  • Enlaces entre roteadores usam um /127 de um /64 reservado, sem o ID de interface todo em zeros nem os 128 valores do topo, a partir de ffff:ffff:ffff:ff80 (errata 3422); loopbacks usam um /128.
  • Prefixos locais únicos começam com fd e um ID global aleatório de 40 bits, reusam os IDs de sub-rede do plano global e ficam fora do BGP e do DNS global.

Fontes