Uma interface IPv6 raramente tem um endereço só. A (RFC) 7934 conta três ou mais por interface em muitos hosts, entre eles o link-local, o estável, o de privacidade e o do Dynamic Host Configuration Protocol for IPv6 () (RFC 7934, seção 2). O próprio host monta a maioria, por autoconfiguração sem estado (stateless address autoconfiguration, ): "The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers", sem configuração manual nem servidores extras (RFC 4862, seção 1). Os roteadores conduzem o SLAAC, e o DHCPv6 ao lado dele (seção 1), com os Router Advertisements (RAs) e suas opções Prefix Information (PIOs). Depois da leitura, você consegue acompanhar a detecção de endereço duplicado (Duplicate Address Detection, ), decifrar um RA, derivar um identificador de interface (interface identifier, IID), distinguir os modos do DHCPv6, prever o endereço de origem de um host, reconhecer as falhas comuns e ver cada passo com ip, rdisc6, tcpdump e Wireshark.

Um endereço link-local que precisa provar que é único

Um nó forma um endereço link-local sempre que uma interface é habilitada (RFC 4862, seção 5.3): na , o IID anexado a fe80::/64 (RFC 2464, seção 5), dentro do tipo link-local fe80::/10 (RFC 4291, seção 2.4). Os roteadores não devem encaminhá-lo a outros enlaces (RFC 4291, seção 2.5.6), e ele nunca expira (RFC 4862, seção 5.3).

Antes do teste, ele é tentative (provisório): "Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface", DAD antes de atribuir qualquer unicast (RFC 4862, seção 5.4). O teste é uma Neighbor Solicitation (NS) para o endereço provisório, do endereço não especificado ao grupo solicited-node formado com seus 24 bits finais (seção 5.4.2; RFC 4291, seção 2.7.1), uma só por padrão (RFC 4862, seção 5.1), com RetransTimer de 1.000 milissegundos (RFC 4861, seção 10). Uma resposta, ou outro nó testando o mesmo endereço, faz dele uma duplicata, que não pode ser atribuída (RFC 4862, seções 5.4.3 e 5.4.5).

O modificado (64-bit Extended Unique Identifier) insere FFFE no endereço Media Access Control (MAC) e inverte o bit universal/local (U/L): 34-56-78-9A-BC-DE vira 36-56-78-FF-FE-9A-BC-DE (RFC 2464, seção 4):

endereço MAC                          34-56-78-9a-bc-de
inverte o bit U/L (0x34 XOR 0x02)     36-56-78-9a-bc-de
insere ff-fe após o 3º octeto         36-56-78-ff-fe-9a-bc-de
identificador de interface            3656:78ff:fe9a:bcde
endereço link-local                   fe80::3656:78ff:fe9a:bcde
destino do teste DAD (24 bits)        ff02::1:ff9a:bcde

Como ler um Router Advertisement

Os roteadores mandam RAs periódicos por multicast, e um host pode provocar um com uma Router Solicitation (RS) (RFC 4861, seções 3 e 4.1); são os tipos 134 e 133 do Internet Control Message Protocol version 6 () (Internet Assigned Numbers Authority (IANA), ICMPv6 Parameters). O host só aceita RAs de origem link-local e com Hop Limit 255 (RFC 4861, seções 4.2 e 6.1.2), e Router Lifetime 0 indica que o remetente não é roteador default (seção 4.2). Os valores padrão, com as contas (seções 6.2.1, 6.3.7 e 10):

MaxRtrAdvInterval            600 s
MinRtrAdvInterval            0,33 × 600 = 198 s
Router Lifetime              3 × 600 = 1.800 s
Valid Lifetime da PIO        2.592.000 s = 30 dias
Preferred Lifetime da PIO    604.800 s = 7 dias
host sem resposta            1ª RS em até 1 s, 3 RSs a 4 s uma da outra, mais 1 s: 9 a 10 s

As flags ficam no header do RA e em cada PIO; a RFC 9762 acrescentou a P, de DHCPv6 prefix delegation (DHCPv6-PD) (RFC 4861, seções 4.2, 4.6.2 e 6.2.1; RFC 9762, seção 5):

FlagOndeQuando ligadaPadrão
M, managedheader do RAhá endereços disponíveis via DHCPv6desligada
O, otherheader do RAhá outras configurações, como DNS, via DHCPv6desligada
L, on-linkPIOo prefixo serve para determinar o que é on-linkligada
A, autonomousPIOo prefixo serve para SLAACligada
P, DHCPv6-PD PreferredPIOa rede prefere delegação de prefixo a endereços avulsosnão existe na RFC 4861

M e O só sinalizam: a M, que "addresses are available via Dynamic Host Configuration Protocol [DHCPv6]", há endereços no DHCPv6, e a O, que "other configuration information is available via DHCPv6", há outras configurações nele (RFC 4861, seção 4.2). A RFC 4862 removeu as regras de host para elas, sem aposentá-las (RFC 4862, Apêndice C), e "M=0 does not prevent a node from attempting DHCPv6", M=0 não proíbe tentar o DHCPv6 (RFC 4861 errata, errata 8055). O SLAAC, prefixo a prefixo, é decidido pela flag A.

A P pede prefixo delegado em vez de endereços avulsos, e "The P flag is independent of the value of the M and O flags in the RA", independe de M e O (RFC 9762, seção 5); o cliente que a respeita não deve usar SLAAC numa PIO com P e A ligadas (seção 7.1). Se cada dispositivo leva um /64, um /60 vindo do provedor (Internet service provider, ), 2^4 = 16 /64s, se esgota depois de 15 dispositivos (seção 1).

SLAAC: do prefixo ao endereço, e como os tempos de vida o envelhecem

A RFC 4862 testa cada PIO (RFC 4862, seção 5.5.3): "If the Autonomous flag is not set, silently ignore the Prefix Information option", sem A, a opção é ignorada; também se ignora um prefixo link-local ou um Preferred Lifetime maior que o Valid Lifetime; e "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored", prefixo mais IID precisam somar 128 bits. Na Ethernet o IID tem 64 bits, então o SLAAC exige um /64 (RFC 2464, seção 4), como explica sub-redes IPv6 e a fronteira /64. Depois, o IID é anexado (RFC 4862, seção 5.5).

Passado o tempo de vida preferencial, o endereço fica deprecated (em desuso): ainda alcançável, mas fora das comunicações novas; passado o válido, fica inválido (RFC 4862, seções 2 e 5.5.4). Todo RA renova o preferencial, mas um RA não autenticado não baixa o válido a menos de 2 horas, para que um único RA falso não derrube todos os endereços do nó (seção 5.5.3). Com 30 dias pela frente, um endereço que recebe os dois tempos zerados fica em desuso na hora, mas segue válido por mais 2 horas.

A escolha do identificador de interface

Um IID EUI-64 leva o MAC para todo endereço montado com ele e expõe o host a rastreamento entre redes, varredura de endereços e ataques específicos ao dispositivo (RFC 7217, seção 1; RFC 8064, seção 1). Daí a regra: "By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID", nada de MAC estável no IID (RFC 8064, seção 3). Seu padrão recomendado, a RFC 7217, calcula F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key): um IID estável em cada sub-rede e diferente em cada rede (RFC 7217, Abstract e seção 5).

Os endereços temporários (RFC 8981, que tornou obsoleta a RFC 4941) acrescentam, por prefixo, um IID aleatório para as conexões que o host inicia, enquanto o estável recebe as conexões de entrada (RFC 8981, Abstract e seção 2.2). Por padrão valem 2 dias e ficam preferenciais por 1 dia, menos um DESYNC_FACTOR de até 0,4 × 86.400 = 34.560 segundos (seções 3.4 e 3.8), e um observador no enlace, como o roteador default, ainda rastreia todos (seção 1.2). O Linux usa EUI-64 por padrão (addr_gen_mode 0) e, na maioria dos dispositivos, nenhum endereço temporário (use_tempaddr 0) (IP Sysctl).

O Kit de ferramentas IPv6 recupera o MAC de um endereço EUI-64, e fe80::211:22ff:fe33:4455 devolve 00:11:22:33:44:55, cujo Organizationally Unique Identifier (OUI) a Consulta de fabricante por OUI / MAC pode levar a um fabricante; o Playground de Python faz o caminho inverso, de 00:1A:2B:3C:4D:5E a 2001:db8:cafe:1:21a:2bff:fe3c:4d5e.

DHCPv6: com estado, sem estado e delegação de prefixo

Hoje o DHCPv6 é a RFC 9915, publicada em janeiro de 2026 como Internet Standard 102 (STD 102), que torna obsoleta a RFC 8415 (RFC 9915, Abstract). Os clientes enviam para ff02::1:2, o grupo de escopo de enlace All_DHCP_Relay_Agents_and_Servers, e escutam na porta UDP 546; servidores e relay agents, na 547 (seções 5 e 7.2). São três modos:

  • Com estado: Solicit, Advertise, Request e Reply (seção 5.2). Uma identity association for non-temporary addresses (IA_NA) guarda os endereços, renovados em com o servidor de origem ou, em T2, com qualquer um (seção 4.2).
  • Sem estado: um Information-request para opções como DNS, enquanto o SLAAC monta o endereço (seção 5.1), como anuncia a flag O.
  • Delegação de prefixo: uma identity association for prefix delegation (IA_PD) guarda prefixos (seção 4.2); um /48 delegado dá ao roteador do assinante 2^16 = 65.536 /64s para distribuir um por enlace, sem passar do tempo de vida restante da delegação (seção 6.3).

O DHCPv6 deixa lacunas: "Addresses obtained from an IA Address option MUST NOT be used to form an implicit prefix with a length other than 128", o endereço recebido vale como /128 (RFC 9915, seção 18.2.10.1), e "the only mechanism to configure the default router's address automatically is the one using Router Advertisements", só o RA configura sozinho o roteador default (RFC 4862, seção 5.5.2); por isso redes gerenciadas ainda precisam de RAs. Compare com o lease do IPv4.

De onde vêm os servidores DNS

Sem configuração de DNS, o SLAAC não se sustenta em nenhuma rede prática (RFC 8106, seção 1). O DHCPv6 leva OPTION_DNS_SERVERS (23) e OPTION_DOMAIN_LIST (24) (RFC 3646, seções 3 e 4); o RA leva a opção Recursive DNS Server (RDNSS), tipo 25, com tempo de vida padrão de pelo menos 3 × 600 = 1.800 segundos, e zero a retira (RFC 8106, seção 5.1). O host deve usá-la, salvo se o DNS for estático, e "the DNS information from takes precedence over that from RAs for DNS queries", a informação do DHCP vence a do RA (seções 1.2 e 5.3.1). Que resolvers anunciar, veja em resolvers DNS públicos.

Como o host escolhe o endereço de origem

A RFC 6724 ordena as origens candidatas por regras, entre elas escopo adequado (regra 2), nada de endereços deprecated (regra 3), endereços temporários (regra 7) e o maior prefixo em comum (regra 8) (RFC 6724, seção 5). A regra 7 virou o padrão com a RFC 6724 (Apêndice B), mas a implementação pode invertê-la, como faz o use_tempaddr 1 no Linux (IP Sysctl), e tem de deixar a aplicação invertê-la (RFC 6724, seção 5). No exemplo da RFC, o temporário 2001:db8:1::d5e3:7953:13eb:22e8 vence o público 2001:db8:1::2 rumo a 2001:db8:1::d5e3:0:0:1 (seção 10.1); ip addrlabel list mostra os rótulos (labels) que as regras usam (ip-addrlabel(8)).

O que dá errado

Sem RAs, o host fica com endereços link-local e sem rota default (RFC 4862, seções 1 e 5.5.2). Se as três RSs se perdem, a RFC 7559 conta até 30 minutos sem conectividade no pior caso e mantém o host solicitando, com backoff de 4 a 3.600 segundos (RFC 7559, seções 1 e 2); uma interface Linux com forwarding ligado ignora RAs, salvo com accept_ra 2 (IP Sysctl). Contradições não são erro fatal (RFC 4862, seção 5.6): com M ligada e A desligada, hosts sem cliente DHCPv6 ficam só com o link-local (RFC 8106, seção 1.1); com M e O desligadas, alguns roteadores Customer Edge (CE) podem nem iniciar o DHCPv6-PD (RFC 9762, seção 5).

RAs falsos (rogue RAs) se aproveitam da confiança: nada no Neighbor Discovery diz quais vizinhos podem mandar RAs (RFC 4861, seção 11.1), e "the default router address is drawn directly from the source address of the RA message", o roteador default vem da origem do RA (RFC 6104, seção 1). A maioria dos casos relatados é acidental, como o Windows Internet Connection Sharing (ICS) transformando um notebook em gateway 6to4 (seções 2.2 e 2.3; dual-stack e tradução). Um RA falso também pode trazer um endereço RDNSS fraudulento (RFC 8106, seção 7.1) ou repetir a PIO da rede com P ligada, para que os hosts ignorem a A (RFC 9762, seção 10), e um servidor DHCPv6 falso pode distribuir configuração errada (RFC 9915, seção 22.1).

Nos switches, o Router Advertisement Guard () só deixa passar RAs pela porta do roteador, desde que todo o tráfego atravesse esses switches (RFC 6105, seções 2 a 4), e precisa analisar a cadeia inteira de headers IPv6, porque extension headers já driblaram algumas implementações (RFC 7113, Abstract e seção 3); o DHCPv6-Shield, igualmente, descarta mensagens de servidor DHCPv6 fora das portas designadas (RFC 7610, seção 1).

O DAD não é totalmente confiável, e qualquer nó pode responder por um endereço provisório para negá-lo (RFC 4862, seções 5.4 e 6). A RFC 7527 documenta um circuito em loop que refletiu o próprio teste de um roteador e deixou em DAD-failed uma interface que costuma atender milhares de modems de banda larga; a correção põe um nonce aleatório no teste (RFC 7527, seções 2 e 4).

A renumeração deixa prefixos velhos para trás. Um roteador CE que reinicia pode obter um prefixo novo por DHCPv6-PD (RFC 8978, seção 1), enquanto, com os tempos padrão, os hosts levam até 7 dias para aposentar os endereços antigos e 30 dias para removê-los (seção 2). A RFC 9096 pede que o roteador CE não libere o prefixo ao reiniciar e limita os tempos anunciados a 2.700 segundos (45 minutos), o preferencial, e 5.400 segundos (90 minutos), o válido (RFC 9096, seções 3 e 4).

Como ver tudo isso numa rede real

No Linux, ip address show filtra por flag (ip-address(8)) e o rdisc6 solicita RAs (rdisc6(8)):

ip -6 address show dev eth0
ip -6 address show dev eth0 tentative
ip -6 address show proto kernel_ra
ip -6 route
rdisc6 eth0
tcpdump 'icmp6 and icmp6[icmp6type] == icmp6-routeradvert'

As flags dynamic, tentative, dadfailed e temporary selecionam os endereços do SLAAC, os que estão em DAD, os que falharam nele e os da RFC 8981; proto kernel_ra, os instalados por RAs, e cada endereço mostra valid_lft e preferred_lft (ip-address(8)); proto ra e expires marcam as rotas vindas de RAs (ip-route(8)). Saída ilustrativa e simplificada do primeiro comando, num host EUI-64 com endereços temporários:

fe80::3656:78ff:fe9a:bcde/64                                    (nunca expira)
2001:db8:cafe:1:3656:78ff:fe9a:bcde/64   dynamic            valid_lft 2591990  preferred_lft 604790
2001:db8:cafe:1:d5e3:7953:13eb:22e8/64   temporary dynamic  valid_lft 172790   preferred_lft 85790

O rdisc6 mostra a M como Stateful address conf., a O como Stateful other conf., as flags e os tempos de cada PIO, o router lifetime e eventuais servidores RDNSS, mas não o bit P da PIO (código-fonte do ndisc6). Essa expressão de pcap-filter não pega RAs atrás de extension headers, porque icmp6 os supõe ausentes (pcap-filter(7)). No Wireshark, icmpv6.nd.ra.flag.m, icmpv6.nd.ra.flag.o, icmpv6.opt.prefix.flag.a e icmpv6.opt.prefix.valid_lifetime guardam os campos do RA, e icmpv6.opt.prefix.flag.p só existe nas versões 4.6.0 a 4.6.9 (Wireshark, campos de ICMPv6); dhcpv6.msgtype e dhcpv6.iaaddr.ip decodificam o DHCPv6 (Wireshark, campos de DHCPv6). No Windows, Get-NetIPAddress -AddressFamily IPv6 informa PrefixOrigin (RouterAdvertisement, Dhcp) e SuffixOrigin (Link, Random) (Get-NetIPAddress).

O Kit de ferramentas IPv6 classifica o endereço só pelo prefixo, então endereços SLAAC, DHCPv6, RFC 7217 e temporários sob o mesmo prefixo aparecem como global unicast; só o host, por proto kernel_ra ou por PrefixOrigin e SuffixOrigin, mostra qual caminho gerou cada um.

Para lembrar

  • Toda interface forma primeiro um endereço link-local em fe80::/64 e o testa com DAD: uma NS do endereço não especificado para o grupo solicited-node dele, aqui ff02::1:ff9a:bcde.
  • M e O só dizem o que o DHCPv6 oferece; a flag A de cada PIO decide o SLAAC, a L, o on-link, e a P (RFC 9762) pede delegação de prefixo.
  • O SLAAC ignora a PIO se prefixo mais IID não somarem 128 bits; na Ethernet, só um /64 gera endereços.
  • IIDs estáveis devem seguir a RFC 7217, não o endereço MAC; os temporários da RFC 8981 valem, por padrão, 2 dias e ficam preferenciais por 1 dia.
  • O DHCPv6 (RFC 9915) concede endereços e prefixos, mas o roteador default e o comprimento do prefixo ainda vêm dos RAs.
  • Os servidores DNS chegam na opção RDNSS do RA (tipo 25) ou na opção 23 do DHCPv6, e o DHCPv6 vence se vierem os dois.
  • Um RA não autenticado não baixa o tempo de vida válido a menos de 2 horas, então os padrões de 7 e 30 dias mantêm vivos prefixos velhos; a RFC 9096 recomenda 45 e 90 minutos.

Fontes