Introdução

---

Nos anos 1990, a World Wide Web passou por um verdadeiro boom. Milhares de empresas começaram a oferecer serviços on-line e, consequentemente, precisavam de endereços IPv4 públicos para que seus servidores fossem roteáveis na Internet.

Como o IPv4 possui um limite físico de aproximadamente 4,3 bilhões de endereços (2³²), mesmo com técnicas como CIDR, NAT e a reutilização de blocos, ficou claro já naquela década que a alocação acabaria, fato consumado gradativamente entre 2011 e 2015, quando os Registros Regionais de Internet (RIRs) esgotaram seus estoques.

Para garantir a continuidade da expansão da rede, a Internet Engineering Task Force (IETF) iniciou a criação do próximo protocolo que viria a substituir o IP versão 4, foi então que começou a nascer o IPv6, definido na RFC 2460 e atualizado na RFC 8200.

Vale ressaltar que o projeto como um todo foi finalizado, mas ainda sofre atualizações quando necessário para tornar a Internet um lugar cada vez melhor.

A Hierarquia de Alocação de Endereços IP na Internet

---

Vamos explorar agora como essa estrutura é organizada, começando pelas entidades centrais e indo até as organizações regionais e locais, que lidam com a distribuição de recursos na internet, como endereços IP e domínios.

Internet Engineering Task Force (IETF)

---

A IETF (Internet Engineering Task Force) é uma comunidade internacional aberta de projetistas de redes, operadores, fornecedores e pesquisadores, criada em 1986 e formalizada em 1992, que desenvolve e mantém os padrões técnicos fundamentais da internet por meio da publicação dos Request for Comments (RFCs). Seu trabalho é voluntário e público, conduzido em listas de discussão e em Grupos de Trabalho (WGs) que investigam temas como roteamento, segurança, transporte, aplicações e operações de rede.

A governança da IETF segue um modelo multissetorial colaborativo, sem fins lucrativos, organizado em torno de três pilares: o Internet Architecture Board (IAB)¹, responsável por orientação arquitetural, o Internet Engineering Steering Group (IESG), que revisa e aprova RFCs, e a Internet Research Task Force (IRTF)³, dedicada a pesquisas de longo prazo. A IETF Trust mantém direitos autorais e marcas, garantindo que as especificações permaneçam de domínio público.

Para que os protocolos operem consistentemente, a IETF define códigos e valores únicos (portas TCP/UDP, tipos ICMP, algoritmos de segurança, entre outros) que são registrados pela IANA, hoje operada pela PTI sob contrato com a ICANN. Esse arranjo está formalizado no Memorando de Entendimento RFC 2860 e em acordos suplementares anuais que estabelecem metas de desempenho para a manutenção dos registros de parâmetros de protocolo.

O fluxo típico de padronização começa com um Internet-Draft submetido por qualquer participante. Após discussão em lista e reuniões presenciais ou virtuais, o documento pode ser adotado por um WG, revisado por pares, submetido ao IESG e, se aprovado, publicado como RFC. Os RFCs são classificados como Informational, Experimental, BCP (Best Current Practice) ou Standard Track, nesta última trilha, um protocolo evolui de Proposed Standard a Internet Standard mediante interoperabilidade comprovada.

A IETF realiza três reuniões presenciais por ano (IETF Meeting), numeradas sequencialmente, rotativas entre as regiões, complementadas por interim meetings virtuais e um Hackathon que estimula implementações de código aberto. Todo o processo decisório ocorre em inglês e é regido pelo princípio de rough consensus and running code, que busca acordo técnico amplo e comprovação prática antes da padronização.

Ao longo das décadas, a IETF produziu milhares de RFCs que especificam desde o DNS (RFC 1034/1035) e o BGP (RFC 4271) até o IPv6 (RFC 8200) e o TLS 1.3 (RFC 8446). Essa produção contínua garante a interoperabilidade global da internet, mantendo-a escalável, segura e compatível com novas tecnologias.

ICANN

---

A ICANN (Internet Corporation for Assigned Names and Numbers) é uma organização sem fins lucrativos criada em 1998, responsável por coordenar, através da função IANA, a atribuição de identificadores únicos da internet, nomes de domínio, blocos de endereços IP, números de sistemas autônomos (ASNs) e registros de parâmetros de protocolos (como números de porta TCP/UDP, tipos MIME e códigos de protocolo IP). Essa coordenação segue um modelo multissetorial, que envolve governos, setor privado, sociedade civil, comunidade técnica e acadêmica, por meio de estruturas formais como as Supporting Organizations (GNSO, ccNSO e ASO¹) e os Advisory Committees (GAC, SSAC, ALAC², RSSAC³).

No Sistema de Nomes de Domínio (DNS), a ICANN mantém e assina criptograficamente o arquivo da zona-raiz. No entanto, a hospedagem dos servidores-raiz é descentralizada, 12 organizações independentes operam os 13 servidores raiz (A a M), por meio de redes anycast. A ICANN fica responsável de operar apenas o servidor L-Root.

A missão central da ICANN é garantir a segurança, estabilidade e interoperabilidade da internet global. Isso inclui a coordenação de políticas para domínios genéricos de topo (gTLDs, como .com, .org e etc) e a delegação de códigos de país (ccTLDs, como .br, .mx e etc). No caso dos ccTLDs, a ICANN não define as regras internas de registro, delegando essa responsabilidade ao gestor local, conforme estabelecido em políticas da ccNSO e princípios históricos da RFC 1591. Embora a ICANN não fiscalize conteúdo ou interconexões físicas, ela exige que registries e registrars adotem políticas de mitigação de abuso de DNS (como malware, botnets, phishing e pharming).

A ICANN também supervisiona o processo de criação de novos gTLDs. Inicialmente, a ICANN foi constituída com base em um contrato com o Departamento de Comércio dos Estados Unidos, mas desde outubro de 2016, com a conclusão da IANA Stewardship Transition, a ICANN adotou um modelo multissetorial autônomo, sem vínculo hierárquico com qualquer governo.

Apesar disso, governos nacionais participam do processo decisório por meio do Governmental Advisory Committee (GAC), que emite recomendações não vinculantes sobre políticas públicas relacionadas à internet.

Ao longo do ano, a ICANN realiza três grandes reuniões públicas internacionais, abertas a todas as partes interessadas:

• ICANN Community Forum
• ICANN Policy Forum
• ICANN Annual General Meeting

Esses encontros reúnem representantes dos diversos setores para debater propostas, revisar contratos e aprimorar a governança técnica da internet. Além das reuniões públicas, a ICANN promove workshops regionais, sessões de capacitação técnica e eventos multissetoriais de engajamento, com foco na inclusão de novos participantes no ecossistema global da internet.

Internet Assigned Numbers Authority (IANA)

---

Durante os primeiros anos da ARPANET, a rede começou a ligar dezenas de laboratórios, esses laboratórios tinham que compartilhar um mesmo espaço de endereços, portas e outros identificadores. Em março de 1972, Vint Cerf e Jon Postel que trabalhavam no Information Sciences Institute da USC (USC-ISI) propuseram em um RFC, manter um catálogo central, quem assumiu a tarefa foi Postel.

Nos anos seguintes, Postel atualizou periodicamente essas listas e começou a adicionar blocos de endereços IP e códigos de protocolo. A comunidade logo percebeu que era mais eficiente ter uma única autoridade garantindo que cada número, porta ou código fosse único, condição básica para que diferentes máquinas na rede conseguissem conversar sem conflitos.

O nome Internet Assigned Numbers Authority (IANA) aparece pela primeira vez numa RFC em dezembro de 1988 e é formalmente descrito em 1990 (RFC 1174) como "a autoridade central" do sistema Internet. Na prática, tratava-se de Postel e sua colega Joyce Reynolds executando três trabalhos muito importantes:

• Nomes de domínio: Mantinham a tabela de delegações da futura zona-raiz do DNS.
• Números de sistema autônomo (ASNs) e endereços IP: Reservavam blocos grandes e repassavam a registros regionais assim que estes surgiam. Antes do surgimento dos RIRs, a IANA atribuía blocos diretamente a provedores ou universidades.
• Parâmetros de protocolo: Gerenciavam os registros de portas, tipos ICMP, códigos MIME e etc.

O trabalho de Jon Postel no USC-ISI e até depois do nascimento da IANA sempre esteve sob supervisão do governo dos Estados Unidos, ainda que nunca tenha sido trabalho de um órgão governamental (A DARPA financiou o trabalho até 1991, de 1991 a 1997 o contrato principal passou para a Defense Information Systems Agency - DISA e só então à NTIA). Todo o trabalho executado por Postel e posteriormente pela IANA era inicialmente pago por contratos de pesquisa da DARPA, a agência do Departamento de Defesa que financiava a ARPANET. Esse vínculo significava que Postel prestava contas, inclusive de relatórios técnicos e uso de verba, ao governo norte-americano

Em 1998, o Departamento de Comércio dos EUA publicou o White Paper, um documento que propôs retirar do governo norte-americano a tutela direta sobre os serviços IANA. A Internet comercial explodia em escala global, e havia forte pressão internacional contra o monopólio técnico-administrativo exercido pelos EUA, sobretudo após atritos envolvendo a Network Solutions, até então, única registradora de domínios genéricos, mas vários ccTLDs (ex.: .br) já operavam fora do controle dela.

Para executar essas funções de maneira neutra, aberta ao setor privado e à comunidade técnica mundial, foi criada em 1998 a Internet Corporation for Assigned Names and Numbers (ICANN), uma entidade sem fins lucrativos regida pelas leis da Califórnia.

A ICANN recebeu a missão de garantir estabilidade, segurança, concorrência e coordenação global na atribuição de identificadores únicos da Internet. Isso se traduziu em quatro tarefas principais:

1. Administrar, por meio das Funções IANA, a zona-raiz do DNS (aprovar criação, modificação e remoção de TLDs).
2. Alocar blocos de endereços IPv4, IPv6 e intervalos de ASNs aos Registros Regionais da Internet.
3. Manter os registros de parâmetros de protocolo em cooperação com a IETF.
4. Introduzir concorrência no mercado de domínios (apenas para gTLDs, já que ccTLDs sempre foram administrados à parte), criando um sistema de múltiplas registrars e uma política uniforme de resolução de disputas (UDRP).

Para cumprir esses objetivos, a ICANN foi estruturada como organização multissetorial (governos, setor privado, sociedade civil e comunidade técnica), com Supporting Organizations e Advisory Committees tratando separadamente de nomes, números e aspectos de segurança.

Depois da criação da ICANN, em Fevereiro de 2000, a NTIA assinou com a ICANN o primeiro IANA Functions Contract, concluindo a transição iniciada com o acordo de dezembro 1998. Dessa forma, a ICANN passou a executar as mesmas tarefas, mas continuou legalmente obrigada a cumprir cláusulas e métricas fixadas pelo governo dos EUA.

Tudo mudou em outubro de 2016 com a IANA Stewardship Transition, o contrato com a NTIA expirou e a operação diária foi realocada para a Public Technical Identifiers (PTI), afiliada da ICANN. A partir daí não existe mais uma autoridade governamental única, a supervisão passou a ser feita pela comunidade multissetorial por meio de comitês de revisão e acordos de nível de serviço firmados entre ICANN, RIRs e IETF.

Voltando um pouco no tempo, quando a ICANN foi criada, as funções IANA ainda estavam fisicamente e contratualmente no USC/ISI, onde Jon Postel e sua equipe trabalhavam desde a época da ARPANET. Em janeiro de 1999, em um acordo firmado com o Departamento de Comércio dos EUA (NTIA) e com a própria universidade, todo o "projeto IANA" (pessoal, arquivos, equipamentos e o contrato federal que pagava o serviço) foi transferido para a ICANN. A partir desse momento a IANA passou a operar como um departamento interno da ICANN, responsável pelas mesmas tarefas de sempre (zona-raiz do DNS, blocos de IP, ASNs e registros de protocolo) mas agora sob supervisão da nova corporação multissetorial.

Portanto, a IANA funcionou como um setor (ou departamento) dentro da ICANN. Depois do IANA Stewardship Transition, ela continua vinculada com a ICANN, mas passou a operar dentro da PTI, que é juridicamente separada, embora 100% controlada pela própria ICANN.

Na prática, nada mudou para quem usa a Internet, os mesmos profissionais, sistemas e regras seguem garantindo que nomes, números e códigos não se repitam e que a rede permaneça estável e confiável.

IR - Internet Registry

---

Um Internet Registry (IR) é um termo genérico usado para se referir a qualquer organização responsável pela alocação de recursos numéricos da Internet, como endereços IPv4, IPv6 e números de sistemas autônomos (ASNs). Isso inclui a IANA, os RIRs, NIRs e LIRs, que são classificados conforme sua função e alcance territorial dentro da estrutura hierárquica da Internet.

Mais adiante, vamos detalhar cada um desses tipos com base em seu escopo de atuação. Por enquanto, é importante entender que qualquer entidade que faça a distribuição desses recursos pode ser chamada genericamente de IR, embora receba uma designação mais específica (como RIR ou LIR) para indicar melhor sua função.

A imagem acima (Retirada de https://www.lacnic.net/819/3/lacnic/) mostra a relação entre a IANA e os RIRs/NIRs/LIRs.

Regional Internet Registry - RIR

---

O RIR é uma organização que é responsável por gerenciar a distribuição e alocação de recursos de endereçamento de Internet em uma determinada região geográfica. Os RIRs são responsáveis por distribuir endereços IP (Internet Protocol versão 4 e 6) e números de sistemas autônomos (AS) para provedores de serviços de Internet, organizações e indivíduos em sua região.

A IANA delega recursos da Internet para os RIRs, que acabam seguindo políticas regionais de delegação de recursos para seus clientes, que incluem provedores de Internet e Sistemas Autônomos. Como dito, cada RIR é responsável por um continente ou mais, como é o caso do APNIC. Existem atualmente cinco RIRs que são responsáveis por diferentes regiões do mundo:

RIR	Região atendida
AFRINIC	Todos os países da África e ilhas do Oceano Índico.
APNIC	Região da Ásia e Pacífico (engloba a Oceania).
ARIN	Região do Canada, USA, e algumas ilhas do Caribe.
LACNIC	Região da América Latina e algumas ilhas do Caribe.
RIPE NCC	Região da Europa, Oriente Médio e Asia central.

A divisão geográfica entre os RIRs não segue os limites tradicionais dos continentes. Por exemplo:

• O México pertence ao LACNIC (não ao ARIN)
• A Groenlândia está sob responsabilidade do RIPE NCC
• As Bahamas e outras ilhas do Caribe estão sob o ARIN

As regras de alocação são definidas pela própria comunidade de cada região, por meio de um processo transparente, aberto e colaborativo, fundamentado em debates públicos, propostas documentadas e consenso técnico.

A IANA é quem realiza a alocação inicial de grandes blocos de recursos aos RIRs. Estes, por sua vez, os distribuem a seus membros, como LIRs (Local Internet Registries) e outros titulares de recursos, conforme as políticas estabelecidas regionalmente.

Os cinco RIRs formam coletivamente a Number Resource Organization (NRO), uma estrutura de coordenação sem personalidade jurídica própria, que representa os interesses dos RIRs globalmente. Por meio da Address Supporting Organization (ASO), o NRO assessora a ICANN em questões relacionadas à numeração da Internet.

O objetivo central dos RIRs é garantir a unicidade, rastreabilidade e uso eficiente dos recursos numéricos da Internet, promovendo a estabilidade e resiliência da rede em escala global.

A imagem acima (Retirada de secbitrez.files.wordpress.com) mostra a relação entre a IANA e os RIRs.

NIR - National Internet Registry

---

Os NIRs (National Internet Registry) são organizações que estão sob um determinado RIR, foram criadas para ajudar os RIRs a gerenciar a alocação e gestão dos recursos de numeração IP em um país (economia), por exemplo, o NIC.br é o NIR responsável pelo Brasil, o JPNIC é o NIR responsável pelo Japão.

Os NIRs são uma forma de descentralização da gestão dos recursos de numeração IP, permitindo que cada país (economia) possa ter uma entidade responsável por gerenciar e alocar seus próprios recursos de numeração IP, seguindo as políticas estabelecidas pelos RIRs. Isso permite uma maior eficiência e agilidade na gestão dos recursos, além de permitir que cada país ou região tenha um maior controle sobre seus próprios recursos de numeração IP.

Quando não há NIR, a alocação é direta pelo RIR, ou seja, os ISPs e organizações dos demais países latino-americanos lidam diretamente com o LACNIC, o mesmo vale nas regiões ARIN, RIPE NCC e AFRINIC. As políticas aplicadas são as mesmas para todos, garantindo tratamento equitativo.

Segue alguns dos NIRs existentes:

NIR	Descrição
NIC.br	Responsável pela gestão dos recursos de numeração IP no Brasil.
NIC Mexico	Responsável pela gestão dos recursos de numeração IP no México.
KISA	Responsável pela gestão dos recursos de numeração IP na Coreia do Sul. Sucessora da antiga KRNIC.
JPNIC	Responsável pela gestão dos recursos de numeração IP no Japão.
TWNIC	Responsável pela gestão dos recursos de numeração IP em Taiwan.
CNNIC	Responsável pela gestão dos recursos de numeração IP na China.

Um exemplo de NIR no Brasil é o NIC.br/Registro.br, é o único National Internet Registry reconhecido pelo LACNIC o Brasil. O NIC.br recebe prefixos IPv4/IPv6 e números ASN do LACNIC e faz as distribuições internas para organizações brasileiras por meio do Registro.br.

LIR - Local Internet Registry

---

Um LIR (Local Internet Registry) é uma organização que recebeu um bloco de endereços IP de um Registro Regional da Internet (RIR) e que atribui esses endereços a seus clientes e/ou à própria infraestrutura. Ele atribui principalmente espaço de endereço aos usuários dos serviços de rede que fornece. Os LIRs podem ser Provedores de Serviços de Internet (ISPs), grandes corporações, universidades e CDNs. É necessário ser membro de um RIR para se tornar um LIR, o que implica em firmar um contrato de serviços e assumir o pagamento de taxas periódicas definidas pelo registro regional.

Um provedor de serviços de Internet (ISP) é uma organização que fornece acesso à Internet. Os provedores de serviços de Internet podem ser de propriedade da comunidade e sem fins lucrativos ou de propriedade privada e com fins lucrativos.

Abaixo podemos conferir alguns LIR que operam no Brasil:

Nome	ASN(s) de referência
Claro S.A.	AS28573
Telefônica Brasil S.A. (Vivo)	AS26599 / AS10429
TIM S.A.	AS26615
Oi S.A.	AS7738
Algar Telecom S.A.	AS16735
Rede Nacional de Ensino e Pesquisa (RNP)	AS1916
Locaweb Serviços de Internet S.A.	AS27715
UOL Diveo / Companhia UOL	AS263339

Alocação de endereços Globais

---

Como foi explicado acima, os endereços globais estão sob a administração da IANA que no caso do IPv6 acaba distribuindo um /12 para cada um dos cinco RIR, cada RIR pode receber um ou mais desses blocos conforme a utilização.

A alocação mínima para ISPs fornecida pelo NIC.br é um bloco /32, no entanto, alocações maiores podem ser feitas mediante apresentação de justificativa de utilização. Já as empresas, recebem um /48 e os usuários finais deveriam receber um /64 (para dispositivos móveis ou ISP que ainda não quer entregar /56) a /56 (para residências).

Vale lembrar que a RFC 4291 fixa o prefixo /64 apenas para enlaces que utilizam SLAAC (Stateless Address Autoconfiguration). Para outras finalidades existem exceções formalizadas:

• RFC 6164 recomenda /127 em links ponto-a-ponto, reduzindo espaço desperdiçado e mitigando varreduras.
• RFC 7136 removeu o "significado especial" dos 64 bits da interface identifier, permitindo prefixos mais longos quando SLAAC não é necessário.

Assim, o requisito de "não ultrapassar /64" aplica-se exclusivamente a redes que dependem de SLAAC. Infraestruturas puramente roteadas podem usar /127, /126 ou qualquer tamanho coerente com a política adotada.

Quando um bloco é alocado de um RIR para um LIR (ou de um NIR para uma organização local) e depois designado internamente, o prefixo padrão costuma ser /48. Esse /48 comporta 2¹⁶ = 65 536 sub-redes /64 independentes, número que atende com folga às necessidades da maioria das empresas.

Endereçamento IPv6

---

O IPv6 possui um total de 128 bits (contra 32 bits do IPv4). Para torná-lo legível, dividimos esses 128 bits em 8 grupos de 16 bits (chamado de hexadecateto) e separamos cada grupo com "dois pontos", assim: 2001:0db8:0000:0000:0000:ff00:0042:8329.

Cada caractere que aparece nessa forma hexadecimal vale 4 bits, por isso quatro caracteres completam um grupo de 16 bits. Como escrever tanto zero seria cansativo, a regra permite eliminar zeros à esquerda dentro de cada grupo e também trocar um trecho contínuo de grupos 0000 por ::, mas esse atalho pode ser usado só uma vez em cada endereço. Um exemplo abreviado fica 2001:db8::ff00:42:8329.

No IPv4 falávamos em parte de rede e parte de host, no IPv6 a mesma ideia recebeu nomes novos. Chamamos de prefixo a parte que identifica a rede, e chamamos de interface identifier a parte que identifica o dispositivo dentro dessa rede.

Na maioria das situações o prefixo ocupa 64 bits e os outros 64 bits formam o identificador da interface, o que permite que o próprio equipamento crie seu endereço automaticamente por SLAAC. Em links especiais, como conexões ponto-a-ponto entre roteadores, é comum usar prefixos mais longos, por exemplo /127, porque não há necessidade de reservar tantos endereços no mesmo enlace.

Dessa forma, preservamos o espaço de endereços e ainda garantimos funcionamento simples e previsível para quem está começando a trabalhar com IPv6.

A imagem acima ilustra os campos do endereçamento IPv6.

Tipos de endereços

---

No IPv6 existem três formas básicas de endereçar pacotes:

• Unicast
  É o endereço que identifica um único dispositivo. Quando você envia um pacote a um unicast, ele sai da origem e chega só naquele destino, comunicação "um-para-um", como no IPv4.

• Multicast
  Identifica um grupo de dispositivos que optam por receber pacotes enviados a esse endereço. O mesmo pacote é entregue a todos os membros do grupo, comunicação "um-para-vários". Como no IPv4, há faixas reservadas para diferentes finalidades (ex.: ff02::1 para "todos os nós" da própria rede local, ff02::2 para "todos os roteadores" do enlace, etc.).

• Anycast
  Usa um endereço que pode estar configurado em vários dispositivos ao mesmo tempo, mas o roteamento só entrega o pacote ao integrante que estiver "mais próximo" segundo as métricas da rede. Por isso dizemos que é "um-para-um dentre muitos". É muito usado em serviços distribuídos, por exemplo, servidores DNS raiz espalhados pelo mundo compartilham o mesmo endereço anycast.

No IPv6 não existe mais o endereço de broadcast. Quando precisamos alcançar todos os dispositivos do mesmo enlace, usamos o endereço multicast ff02::1, conhecido como All-Nodes. Qualquer pacote enviado a esse destino é entregue a todas as interfaces ativas na rede local, sem ultrapassar roteadores, cumprindo o papel que o broadcast tinha no IPv4.

Unicast

---

Um endereço unicast identifica uma única interface de rede. No IPv6 existem três categorias principais:

Global Unicast

---

São endereços roteáveis na Internet, se assemelha aos endereços públicos IPv4.
Foi definido um 2000::/3 para englobar todos os endereços roteáveis na Internet, tendo início em 2000:: e terminando em 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, ou seja, é um /3.

Link local

---

Esse tipo de endereço é gerado automaticamente para ser usado exclusivamente dentro do enlace, ou seja, é um endereço local. É por meio desse endereço que o SLAAC (Stateless Address Auto-configuration) acontece, esse endereço é usado para Descoberta de Vizinhança no âmbito geral.

Quando o computador é ligado, ele cria um endereço IPv6 link-local combinando o prefixo fe80::/64 com um identificador de interface (IID) de 64 bits. Esse IID pode ser gerado de forma aleatória, para aumentar a privacidade, ou gerado a partir do MAC pelo método EUI-64 (divide-se o MAC ao meio, insere-se fffe no centro e inverte-se o sétimo bit). O resultado é um endereço temporário, ele ainda não pode ser usado até que o sistema confirme que não existe outro equipamento com o mesmo IID no enlace. Para confirmar isso, ele executa o procedimento chamado Duplicate Address Detection, conhecido pela sigla DAD.

Primeiro o host cria, a partir dos 24 bits finais do endereço temporário, um endereço multicast especial chamado Solicited-Node. Esse endereço começa sempre em ff02::1:ff00:0/104 e termina com aqueles mesmos 24 bits, de modo que somente máquinas que poderiam ter um IID idêntico fazem parte desse grupo. Exemplo: Se o endereço temporário é fe80::1a2b:3c4d:5e6f:1234, o grupo multicast será ff02::1:ff6f:1234.

Em seguida o host envia uma mensagem Neighbor Solicitation para o endereço Solicited-Node usando o endereço de origem não especificado (::). Essa mensagem pergunta, em essência, "alguém já está usando este endereço link-local?".

O host espera por uma resposta durante um curto intervalo definido na RFC 4862. Se outro dispositivo possuir o mesmo endereço, ele responde com uma Neighbor Advertisement e o endereço é considerado duplicado, nesse caso, o sistema abandona o IID e tenta outro valor aleatório. Se não houver resposta, o endereço é declarado único, sai do estado temporário e passa a ser válido e preferido na interface. A partir desse momento, o equipamento já pode dialogar com roteadores em fe80::/64, trocar mensagens de descoberta de vizinhança e prosseguir com a autoconfiguração ou com o recebimento de um prefixo global.

Com o endereço livre, o host vai usar um processo chamado de EUI-64 para criar o endereço de Link Local e atrelar o Solicited Node ao Link Local. Com o Link Local devidamente atrelado a interface o host pode então começar outros processos de comunicação na Rede.

O endereço de Link Local se assemelha ao apipa do IPv4, tendo o prefixo FE80::/64 no IPv6.

Unique Local Address (ULA)

---

Um Unique Local Address (ULA) é o equivalente, no mundo IPv6, aos endereços privados do IPv4, e não devem ser roteados na Internet, ou seja, seu uso é exclusivo para uso interno de uma rede, como: rede de uma empresa (interno apenas), laboratório ou residência. Foi usado um endereço FC00::/7 para essa finalidade. A preferencia sempre deve ser usar endereços públicos, salvos algumas exceções como as impressoras ou Redes onde não devem ter acesso a Internet. O bloco FC00::/7 foi divido em dois blocos /8:

• FC00:/8
  Esse bloco deve ser alocado por uma Autoridade da Internet responsável por atribuir um identificador global aleatório. Mmas nunca houve acordo sobre como fazer isso, então ele permanece reservado e sem uso prático (marcado como "indefinido").

• FD00:/8
  Esse bloco por outro lado é o mais próximo que temos dos endereços IPv4 privados e pode ser usado da mesma forma. A RFC 4193 recomenda gerar um número de 40 bits de forma pseudoaleatória e encaixá-lo logo após o prefixo FD00. Esse procedimento cria um espaço como fdxx:xxxx:xxxx::/48, único o bastante para evitar conflito caso duas redes se conectem algum dia por VPN. Mesmo com essa facilidade, a prática geral continua sendo dar preferência a prefixos globais roteáveis e recorrer ao ULA apenas quando o isolamento total da aplicação fizer sentido.

Anycast

---

O Anycast é uma técnica em que o mesmo endereço IP unicast é configurado em vários servidores espalhados por lugares diferentes. Esses servidores anunciam esse endereço na rota global e os roteadores, seguindo a métrica normal do BGP, encaminham cada pacote para o ponto que aparenta estar mais perto ou ter o caminho mais barato.

Para o usuário, parece que existe um único servidor, mas na prática ele sempre fala com a instância mais próxima. Quem decide o destino final é apenas o roteador, sem precisar de software especial no servidor. Essa ideia é muito popular em redes de entrega de conteúdo (CDN), nos servidores raiz do DNS, em serviços de balanceamento de carga, proxies e até filtros contra ataques distribuídos, porque reduz latência e reparte o tráfego de forma automática.

Multicast

---

No IPv6 o multicast deixou de ser recurso opcional. Ele substitui o broadcast do IPv4 em tarefas básicas como descoberta de vizinhança, autoconfiguração e troca de rotas. Todos os endereços multicast começam com FF, formando o bloco ff00::/8, cuja estrutura é mostrada na imagem abaixo, os dois primeiros octetos são FF, depois vêm 4 bits de flags, 4 bits de escopo (que definem até onde o pacote pode viajar) e, por fim, o identificador do grupo.

O grande benefício está na criação de grupos de interfaces, cada dispositivo decide a quais grupos quer pertencer e só recebe pacotes destinados a esses grupos, o que evita sobrecarregar a rede.

Qualquer host ligado a uma rede IPv6 já pertence automaticamente ao grupo All-Nodes, identificado por ff02::1. Esse endereço alcança todos os nós do mesmo enlace e, por isso, elimina a necessidade de broadcast. O grupo All-Routers, ff02::2, reúne todos os roteadores presentes nesse mesmo enlace.

Outro grupo muito usado é o Multicast-all-routers no qual é usado o endereço ff02::2, esse endereço é usado para comunicação com todas as interfaces dos roteadores.

A imagem acima ilustra os campos do endereços multicast.

A tabela a seguir mostra alguns grupos padronizados descritos nas RFC 2375 e RFC 4291.

Endereço	Escopo	Descrição
ff01::1	Interface	Todas as interfaces (all-nodes)
ff01::2	Interface	Todas os roteadores (all-routers)
ff02::1	Enlace	Todas os nós (all-nodes)
ff02::2	Enlace	Todas os roteadores (all-routers)
ff02::5	Enlace	Roteadores OSPFv3
ff02::6	Enlace	Roteadores OSPFv3 (designados)
ff02::7	Enlace	Roteador RIPng
ff02::a	Enlace	Protocolo EIGRP (Cisco)
ff02::d	Enlace	Todas os roteadores PIM
ff02::1:2	Enlace	Agentes DHCP
ff02::1:ffXX:XXXX	Enlace	Solicited-node
ff05::2	Site	Todos os roteadores (all-routers)
ff05::1:3	Site	Servidores DHCP em um site
ff05::1:4	Site	Agentes DHCP em um site
ff0X::101	Variado	Network Time Protocol (NTP)

Esses grupos ilustram como o multicast é essencial no IPv6, cada função de rede (roteamento, autoconfiguração, serviços) tem seu endereço próprio, permitindo que as mensagens cheguem somente a quem realmente precisa recebê-las e mantenham o tráfego local sob controle.

curiosidade

No Linux, para ver a lista de grupos nos quais cada interface já está inscrita, pode usar o comando ip -6 maddr show.

Endereços especiais

---

Existem alguns endereços e blocos IPv6 especiais, são eles:

• Localhost - ::1 ou ::1/128

  Equivale ao 127.0.0.1 do IPv4. Fica sempre preso à pilha local, nunca sai pela interface de rede. O formato expandido é 0:0:0:0:0:0:0:1.

• Rota default - ::/0

  Indica qualquer destino na tabela de rotas, assim como 0.0.0.0/0 no IPv4. Quando apontada para um roteador, torna-se o gateway default.

• 6to4 - 2002::/16

  Endereços construídos automaticamente a partir de um IPv4 público (2002:<IPv4‐hex>/48). Foram propostos para túnel sem configuração, mas o método caiu em desuso e está obsoleto desde 2015.

• Documentação - 2001:db8::/32

  Reservado pela RFC 3849 para livros, artigos, slides e laboratórios. Garantia de que nenhum endereço real será divulgado por engano.

• IPv4 mapeado - ::ffff:192.168.0.10

  Nos 128 bits totais, os primeiros 80 bits são zero, os 16 seguintes são ffff, e os 32 finais trazem o IPv4. É usado internamente por pilhas dual stack para que um socket IPv6 aceite conexões IPv4 sem conversão de código. A imagem abaixo mostra exatamente essa quebra em blocos:
  0.0.0.0 | ffff | 192.168.0.10.

  
  

  

  A imagem acima ilustra os campos do endereços multicast.

  
  

  Na representação acima foi utilizado um endereço IPv4 privado, mas na Internet você verá ou utilizará endereços IPv4 públicos.

• Link-Local Unicast - fe80::/10

  Gerado automaticamente em cada interface. Só vale na própria rede física (enlace), serve para SLAAC, Neighbor Discovery e comunicação com o roteador mesmo quando ainda não existe endereço global.

• Global Unicast - 2000::/3

  Espaço roteável na Internet, equivalente aos IPs públicos do IPv4. Qualquer prefixo atribuído por um RIR ou NIR virá daqui.

Calculando endereços

---

Vamos aprender a calcular endereços IPv6 e entender como funciona o processo. Primeiro, lembre-se que um endereço IPv6 possui 128 bits distribuídos em oito grupos de 16 bits (chamados hexadecatetos), separados por dois-pontos. Na prática, isso significa que, a cada grupo que acrescentamos, avançamos 16 bits no prefixo.

O projeto do IPv6 reserva os primeiros 64 bits para o prefixo da rede e os 64 bits seguintes para o identificador da interface (isto é, para o host). Manter um /64 para a parte de host não é apenas boa prática, vários mecanismos como a autoconfiguração SLAAC e recursos de segurança em switches, presumem esse tamanho. Se você usar um prefixo de host mais curto ou mais longo, certas funções podem simplesmente deixar de funcionar.

Veja o exemplo abaixo e repare como cada grupo acrescenta exatamente 16 bits ao prefixo:

Endereço: 2001:0db8:cafe:dado:faca:ca5a:f0ca:dead

Grupo 1  → 2001:                                   = /16
Grupo 2  → 2001:0db8:                              = /32
Grupo 3  → 2001:0db8:cafe:                         = /48
Grupo 4  → 2001:0db8:cafe:dado:                    = /64   ← limite usual entre prefixo e host
Grupo 5  → 2001:0db8:cafe:dado:faca:               = /80
Grupo 6  → 2001:0db8:cafe:dado:faca:ca5a:          = /96
Grupo 7  → 2001:0db8:cafe:dado:faca:ca5a:f0ca:     = /112
Grupo 8  → 2001:0db8:cafe:dado:faca:ca5a:f0ca:dead = /128

Portanto, quando alguém menciona um prefixo /48, por exemplo, está dizendo que os três primeiros grupos (3 × 16 = 48 bits) identificam a rede e que os 80 bits restantes ainda podem ser divididos em sub-redes ou atribuídos a hosts, sempre respeitando, na etapa final, o limite de /64 para cada enlace onde haverá autoconfiguração.

O endereço IPv6 é escrito em hexadecimal, e cada algarismo equivale a 4 bits. Como um hexadecateto possui quatro algarismos, ele totaliza 16 bits. Quando dizemos que um prefixo é /3, estamos dizendo que apenas os três primeiros bits de todo o endereço ficam fixos, os 125 bits restantes podem variar e formam todas as redes e hosts dentro desse bloco.

Para enxergar isso, pegue o endereço de exemplo 2001::/3. Basta olhar para o primeiro hexadecateto ("2001"), porque nele já encontraremos os três bits que interessam. Escrevendo esses quatro algarismos em binário temos:

A imagem acima ilustra a conversão do IPv6 de hexadecimal para binário.

Após converter para binário, temos o seguinte: 0010 0000 0000 0001. Agora separamos os três primeiros bits 001, e deixamos o restante livre, ficando assim: 0010000000000001.

Esses três bits (001) são o "pedaço de rede" que define todo o bloco /3. Mantendo-os intocados, descobrimos o início e o fim dessa rede: ela começa em 2000:: e vai até 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.

Existem duas formas de se trabalhar com o endereçamento dessa forma, uma delas é não mexer nesses três primeiros bits (em vermelho), nesse caso vamos descobrir onde a rede começa e onde ela termina. A outra forma é mexer apenas no penúltimo bit dos bits reservados, com isso vamos descobrir onde a próxima rede começa.

Calculando o Começo/Final da Rede (sem mexer nos bits reservados)

---

O prefixo /3 indica que apenas os 3 primeiros bits dos 128 bits do endereço são fixos. No bloco 2000::/3 esses 3 bits são 0010 (eles aparecem logo no início do número 2 em hexadecimal). Tudo o que vem depois pode variar, é isso que define o início e o fim da rede.

Primeiro vamos expandir o endereço para vermos ele completo: 2000:0000:0000:0000:0000:0000:0000:0000/3. Agora converta tudo para binário:

 2    0    0    0  :  0    0    0    0  :  0    0    0    0  :  0    0    0    0  :  0    0    0    0  :  0    0    0    0  :  0    0    0    0  :  0    0    0    0  

0100 0000 0000 0000: 0000 0000 0000 0000: 0000 0000 0000 0000: 0000 0000 0000 0000: 0000 0000 0000 0000: 0000 0000 0000 0000: 0000 0000 0000 0000: 0000 0000 0000 0000

Agora vamos isolar os três primeiros bits e transformar todos os bits que são 0 em 1. Assim conseguimos saber onde a rede começa.

001 1 1111 1111 1111: 1111 1111 1111 1111: 1111 1111 1111 1111: 1111 1111 1111 1111: 1111 1111 1111 1111: 1111 1111 1111 1111: 1111 1111 1111 1111: 1111 1111 1111 1111

Agora vamos converter cada hexadecateto de binário para decimal (e depois calcular o hexadecimal) e elevamos cada bit de acordo com a posição, sempre começando da direita para a esquerda:

2³	2²	2¹	2⁰	Total
0	0	1	1	3

O hexadecateto acima foi o primeiro (0011), mas precisamos fazer isso com todos. Como o valor foi 3 em decimal, convertido para hexadecimal será 3 também. Como o restante é tudo 1, vamos calcular apenas um hexadecateto e saberemos de todos:

2³	2²	2¹	2⁰	Total
1	1	1	1	15

O resultado é 15 porque: 2³=8, 2²=4, 2¹=2 e 2⁰=1, ou seja 1+2+4+8=15. O valor 15 em decimal vira F em hexadecimal. O cálculo final será: 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff que é o endereço final da Rede.

A imagem acima ilustra como calcular o final da rede em IPv6.

Calculando a próxima Rede (mexendo nos bits reservados)

---

Agora vamos mudar apenas o penúltimo bit (começando da direita para a esquerda ou o segundo bit se começar da esquerda para a direita) dos bits reservados para calcular a próxima rede. Lembrando que 2000::/3 convertido em binário e pegando os 3 bits teremos: 0010.

2³	2²	2¹	2⁰	Total
0	0	1	0	2

0010 = 2 em hexadecimal

O que vamos fazer é setar o penúltimo bit para positivo (igual a 1) e todos os demais vamos desativar (setando eles com 0):

2³	2²	2¹	2⁰	Total
0	1	0	0	4

0100 = 4 em hexadecimal

Isso nos informa que a próxima rede começa em 4000::/3. Esse foi um exemplo simples, vamos praticar um pouco mais.

A imagem acima ilustra como calcular a próxima rede em IPv6.

ICMP versão 6

---

O ICMPv6 (Internet Control Message Protocol version 6) é uma versão aprimorada do protocolo ICMPv4, foi especificado na RFC 4443. Ele mantém todas as funções da versão anterior e incorpora novos recursos que tornaram obsoletos alguns protocolos separados no IPv4:

• ARP / RARP
  Foram substituídos pelo Neighbor Discovery (mensagens ICMPv6 que resolvem endereços MAC <--> IPv6).

• IGMP
  Substituído pelo Multicast Listener Discovery (MLD), também baseado em ICMPv6. Atua com o gerenciamento de membros de grupos multicast.

O ICMPv6 é um protocolo de camada 3, mas é encapsulado dentro do pacote IP. Isso significa que firewalls operando na camada de rede, com o IPv6, podem bloquear funções extremamente básicas como a descoberta dos vizinhos e a autoconfiguração.

O ICMPv6 é usado por nós IPv6 para relatar erros encontrados no processamento de pacotes e para executar outras funções da camada da Internet, como diagnósticos (ICMPv6 "ping"). O ICMPv6 é parte integrante do IPv6, e o protocolo base (todas as mensagens e comportamentos exigidos por esta especificação) DEVE ser totalmente implementado por cada nó IPv6.

Cada mensagem ICMPv6 é precedida por um cabeçalho IPv6 e zero ou mais cabeçalhos de extensão IPv6. O cabeçalho ICMPv6 é identificado por um valor de Next Header com valor de 58 no cabeçalho imediatamente anterior. (Isso é diferente do valor usado para identificar ICMP para IPv4.)

As mensagens ICMPv6 têm o seguinte formato geral:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Message Body                          +
|                                                               |

O campo type indica o tipo da mensagem. Seu valor determina o formato dos dados restantes. O campo code depende do tipo de mensagem. Ele é usado para criar um nível adicional de granularidade de mensagem. O campo Checksum é usado para detectar corrupção de dados na mensagem ICMPv6 e partes do cabeçalho IPv6.

As mensagens ICMPv6 são agrupadas em duas classes:

• Mensagens de erro
  As mensagens de erro são identificadas como tal por um zero no bit de ordem superior de seus valores de campo de tipo de mensagem. Assim, as mensagens de erro possuem tipos de mensagens de 0 a 127.

• Mensagens informativas
  Mensagens informativas têm tipos de mensagem de 128 a 255.

Segue apenas os tipos de mensagem, não vou colocar os códigos de cada tipo, os códigos dão um detalhe a mais do problema, mas existem muitos códigos para cada tipos de mensagem, para ver a lista completa veja no site da IANA.

Tipo de mensagem	Descrição
1	Destination Unreachable
2	Packet Too Big
3	Time Exceeded
4	Parameter Problem
128	Echo Request (Requisição do ping)
129	Echo Reply (Resposta do ping)
135	Neighbor Solicitation
136	Neighbor Advertisement
141	Inverse Neighbor Discovery Solicitation Message
142	Inverse Neighbor Discovery Advertisement Message
148	Certification Path Solicitation Message
149	Certification Path Advertisement Message

O IPv6 exige suporte a um MTU mínimo de 1280 bytes, mensagens Packet Too Big (Tipo 2) sinalizam quando um enlace no caminho não comporta o tamanho atual do pacote e indicam o novo valor de MTU recomendado.

NDP - Neighbor Discovery Protocol

---

O Neighbor Discovery Protocol (NDP) é um protocolo usado no IPv6 para a descoberta e configuração de vizinhos em uma rede local. O NDP desempenha um papel importante no funcionamento do IPv6, fornecendo várias funcionalidades essenciais. Ele substitui e expande o trio ARP + ICMP Router Discovery + ICMP Redirect do IPv4, condensando tudo em cinco mensagens ICMPv6 (duas em pares (RS/RA e NS/NA) mais o Redirect), cujo tipo está fixado no intervalo 133-137 decimal.

Tipo de mensagem	Descrição
133	Router Solicitation (RS). Usado pelos hosts para encontrar os roteadores da Rede.
134	Router Advertisement (RA). Enviado pelos roteadores da Rede para que os hosts saibam quem é o router.
135	Neighbor Solicitation (NS). Enviado para obter informações de vizinhança.
136	Neighbor Advertisement (NA). Enviado por um host como resposta a uma solicitação (NS).
137	Redirect. O Roteador informa um next-hop mais eficiente no próprio enlace.

Além de descobrir o endereço de enlace do vizinho, o NDP cobre autoconfiguração sem estado (SLAAC), detecção de endereço duplicado (DAD), manutenção de cache com Neighbor Unreachability Detection (NUD) e redirecionamento de rotas locais. A RFC 4861 resume esse conjunto de responsabilidades (ND, RD, SLAAC, Address Resolution, NUD, DAD e Redirect) em uma única pilha.

Alguns dos recursos do NDP incluem:

• Descoberta de vizinhos (Neighbor Discovery)
  O NDP permite que os dispositivos IPv6 descubram os endereços MAC (Media Access Control) dos dispositivos vizinhos em sua rede local. Isso é feito por meio de mensagens de solicitação (Neighbor Solicitation) e de resposta (Neighbor Advertisement).

• Autoconfiguração de endereços (Address Autoconfiguration)
  O NDP permite que os dispositivos IPv6 configurem automaticamente seus endereços IPv6 em uma rede local sem a necessidade de servidores de configuração ou DHCP (Dynamic Host Configuration Protocol). Isso é feito por meio de mensagens de solicitação de roteador (Router Solicitation) e de anúncio de roteador (Router Advertisement).

• Roteamento sem estado (Stateless Address Autoconfiguration - SLAAC)
  O NDP permite que os roteadores anunciem informações de prefixo e parâmetros de rede em mensagens de anúncio de roteador (Router Advertisement). Os dispositivos IPv6 podem usar essas informações para configurar seu endereço IPv6 e obter informações de roteamento sem depender de um protocolo de roteamento dinâmico.

• Redirecionamento (Redirection)
  O NDP permite que um roteador informe a um dispositivo IPv6 uma rota mais eficiente para um destino específico por meio de mensagens de redirecionamento (Redirection). Isso pode ajudar a otimizar o tráfego na rede.

• Detecção de endereço duplicado (Duplicate Address Detection - DAD)
  O NDP fornece um mecanismo para que um dispositivo IPv6 verifique se um endereço que deseja configurar já está em uso na rede. Isso é feito por meio de mensagens de solicitação de endereço (Address Solicitation) e de anúncio de endereço (Address Advertisement).

As mensagens RS são usadas pelos Hosts que desejam encontrar roteadores na rede local, para dessa forma aprender o prefixo que deva ser usado no processo de autoconfiguração (SLAAC) do endereço global. Já os roteadores enviam mensagens RA para anunciá-los periodicamente. As mensagens NS é originada por um host na rede local que deseja obter informações sobre outro vizinho da rede, já o vizinho responde com mensagens NA. Existe três ocasiões onde mensagens NS/NA serão usadas:

• Resolução de endereços físicos;
• Detecção de endereços duplicados;
• Detecção de atividade no vizinho.

Descoberta de Roteadores e Prefixos

---

Quando uma máquina (um host) ingressa na rede, ele envia uma mensagem RS (Router Solicitation) para descobrir quem são os Roteadores da Rede local. O host faz isso originando um pacote ao endereço ff02::2 que é destinada a Multicast-all-routers, dessa forma os Roteadores da Rede respondem com uma mensagem ICMPv6 do tipo RA (Router Advertisement) para o endereço IPv6 Link-Local do host que solicitou.

Dentro da mensagem RA temos informações sobre o prefixo da rede e o endereço do Gateway que deve ser usado pelo Host.

DHCPv6 normalmente não geram mensagens informando o gateway da rede, apenas o prefixo que deva ser usado, por isso, além de usar um DHCPv6 também temos que usar uma aplicação capaz de responder o endereço do Gateway da rede.

Isso pode ser feito usando o RADVD.

Uma mensagem RA é enviada periodicamente como informado acima, em mensagens periódicas essa mensagem é enviada para o destino ff02::1 que é multicast-all-nodes.

Resolução de endereços físicos

---

Quando os dispositivos estão se comunicando dentro da mesma rede local, eles utilizam o endereço MAC em vez do endereço IP. O endereço IP é usado para identificar exclusivamente um host em diferentes redes, permitindo a comunicação entre redes diferentes. No entanto, dentro de uma mesma rede local, a comunicação é feita com base no endereço físico do dispositivo, conhecido como endereço MAC.

O endereço MAC é um identificador único atribuído a cada placa de rede durante a fabricação. Ele é composto por uma sequência de 48 bits (geralmente representados em notação hexadecimal) e é usado na camada de enlace de dados para identificar exclusivamente um dispositivo em uma rede local. O endereço MAC é utilizado pelos dispositivos na mesma rede para enviar e receber pacotes diretamente uns dos outros, sem a necessidade de roteamento.

No IPv6 a responsabilidade de Resolução de endereços lógicos em endereços físicos é responsabilidade do NDP, por meio de mensagens ICMPv6 do tipo 135 e 136. Nesse cenário é o Sistema Operacional que mantém essa tabela, switches também possuem uma tabela desse tipo, porém, armazenam apenas o MAC e a porta no qual cada MAC está.

Quando uma máquina deseja se comunicar com outra no mesmo enlace mas não sabe o endereço MAC, primeiro o Host que deseja se comunicar enviar uma mensagem para o multicast-solicited-node do host, imaginemos que o IPv6 do host B seja 2001:db8:1::b, o endereço usado pelo host A será ff02::1:ff00:000b.

A mensagem Solicited-node usa o formato ff02::1:ffXX:XXXX, onde XX:XXXX são os últimos 24 bits do endereço IPv6.

O campo Target Address do ICMPv6 leva o IPv6 de B, de modo que qualquer nó que receba o NS saiba exatamente que o vizinho em questão é B e possa atualizar o próprio cache de forma imediata. Na mesma mensagem segue a opção Source Link-Layer Address (tipo 1) contendo o MAC de A.

A imagem acima ilustra parte da descoberta de endereço MAC usando ND em IPv6.

Quando B receber a mensagem NS, vai reconhecer seu próprio endereço IPv6 no Target Address. O Host B vai então responder com um Neighbor Advertisement unicast para A e inclui o seu MAC na opção Target Link-Layer Address (tipo 2). Assim que A recebe o NA, cria a entrada 2001:db8:1::b → BB:BB:BB:BB:BB:BB na Neighbor Cache. Já o B, por sua vez, já aprendeu o MAC de A a partir do NS que chegou.

A imagem acima ilustra parte da descoberta de endereço MAC usando ND em IPv6.

Detecção de endereços duplicados

---

Endereços IP duplicados são um problema, já que seria difícil saber para quem entregar, de fato, seria entregue no enlace local usando o MAC, mas para outras redes seria uma problema grande, mesmo dentro da rede local poderia acabar entregando para o host errado. O NDP implementa o DAD (Duplicate Address Detection), antes de atribuir qualquer endereço IPv6 para uma interface.

Antes de um host configurar um endereço IPv6 numa interface, ele vai gerar uma mensagem NS com o endereço multicast-solicited-node gerado a partir do endereço que seria atribuído a sua interface. O endereço de origem é configurado como sendo :: (já que ele não possui endereço), o IPv6 completo é colocado no campo target. Se algum host responder um NA gerado a partir do NS, o host saberá que o endereço IPv6 já está em uso, se não receber nenhum NA após um período, o endereço pode ser usado.

Detecção de atividades no vizinho

---

É usado para tentar detectar se um Roteador se tornou inativo por meio de mensagens NS/NA. Após detectar uma falha, o host envia 3 mensagens NS tendo o endereço unicast do roteador como destino. Se depois de um tempo o host receber um NA, significa que o Roteador está operacional novamente e nada de mais acontece, se não receber nada o host exclui a relação de IPv6/MAC da tabela e procura por um novo Roteador na rede.

Redirecionamento de rota

---

A mensagem ICMPv6 do tipo 137, conhecida como Redirect Message, é enviada por um roteador para informar a um host que existe um roteador melhor (em termos de caminho) para alcançar determinado destino. Essa mensagem tem o objetivo de otimizar o roteamento dentro de uma rede local, evitando que pacotes sejam enviados para um roteador que precisará repassá-los novamente, quando há um caminho mais eficiente disponível.

O funcionamento é bem parecido com a funcionalidade de redirecionamento do ICMPv4, mas no contexto do IPv6 e respeitando as diretrizes do protocolo, como a exigência de que o host e os roteadores estejam no mesmo segmento de rede.

EUI-64

---

O EUI-64 (Extended Unique Identifier) é um mecanismo utilizado pelo IPv6 para gerar automaticamente a parte de identificação do host (interface ID) de um endereço unicast com base no endereço MAC da interface de rede.

Funciona assim, a interface recebe de um roteador, via SLAAC (Stateless Address Autoconfiguration), um prefixo de rede, geralmente um /64. Para completar os 128 bits do endereço IPv6, ela precisa gerar os 64 bits restantes que identificam unicamente a interface na rede. É aí que entra o EUI-64.

No método EUI-64, o endereço MAC da interface (normalmente de 48 bits) é expandido para 64 bits com a inserção do valor fixo FFFE no meio do MAC. Além disso, o sétimo bit (bit "universal/local") do primeiro octeto do MAC é invertido para indicar que o endereço foi modificado localmente.

Por exemplo, suponha um MAC 00:1A:2B:3C:4D:5E. O EUI-64 correspondente seria 021A:2BFF:FE3C:4D5E. O MAC original é 00:1A:2B:3C:4D:5E. O primeiro octeto é 00, que em binário é 00000000.

Agora, olhe para o sétimo bit desse octeto (os bits são contados a partir do mais significativo, da esquerda para a direita, e começando em 0). O sétimo bit é 0, ma como ele precisa ser invertido, ficará bit 1, também chamado de Universal/Local bit (U/L). Ele indica se o endereço foi atribuído globalmente (0) ou localmente (1).

• 00000000 (original) → o bit U/L (bit 1) está em 0.
• Invertendo o bit U/L: 00000010 → isso dá 0x02 em hexadecimal.

Por isso, o primeiro octeto do identificador gerado vira 02, ficando 02, seguido de parte inicial do MAC 1A:2B, seguido do prefixo FF:FE e finalizando com o restante do MAC 3C:4D5E.

• 02 → 7° Bit convertido
• 1A:2B → primeiros dois octetos seguintes
• FF:FE → valor fixo inserido no meio
• 3C:4D:5E → últimos três octetos do MAC

O resultado é combinado com o prefixo da rede, formando um endereço completo, como 2001:db8:abcd:0012:021A:2BFF:FE3C:4D5E.

Esse processo automatiza a configuração de endereços e garante unicidade na rede local, desde que os endereços MAC também sejam únicos. Mas vale lembrar que esse método pode levantar questões de privacidade, pois o endereço IPv6 resultante pode ser usado para identificar persistentemente um dispositivo. Por isso, muitos sistemas operacionais modernos usam endereços aleatórios temporários como alternativa.

Autoconfiguração Stateless - SLAAC

---

A autoconfiguração stateless, conhecida como SLAAC (Stateless Address Autoconfiguration), é uma das funcionalidades mais práticas e elegantes do protocolo. Ela permite que um host configure automaticamente seu próprio endereço IPv6 sem depender de um servidor DHCPv6.

O processo acontece em duas etapas principais: descoberta do prefixo e geração do identificador da interface.

Primeiro, o host envia uma mensagem Router Solicitation (RS) para descobrir se há roteadores na rede. Um roteador que receba essa RS responde com uma Router Advertisement (RA). Esse RA pode conter diversas informações, mas o essencial para o SLAAC é o prefixo de rede (por exemplo, 2001:db8:1::/64) e a indicação de que a autoconfiguração está permitida, via o flag A (Autonomous Address Configuration) ativado.

Com esse prefixo em mãos, o host precisa completar os 128 bits de seu endereço. Isso é feito gerando localmente os 64 bits restantes, que formarão a parte de identificação da interface. Isso pode ser feito com o método EUI-64 (como conversamos antes), ou com um identificador aleatório, caso o sistema esteja configurado para usar endereços temporários, uma medida de privacidade muito comum hoje em dia.

Por fim, o host verifica se o endereço gerado é único na rede, enviando uma mensagem NS (Neighbor Solicitation) para realizar o processo chamado DAD (Duplicate Address Detection). Se ninguém responder, o endereço é considerado válido e é atribuído à interface.

O SLAAC é chamado de "stateless" porque o roteador não mantém nenhuma informação sobre os endereços atribuídos aos hosts, ele apenas anuncia o prefixo. Toda a lógica da configuração acontece no próprio host.

Essa abordagem é extremamente útil em redes simples, como redes domésticas ou redes corporativas pequenas, pois dispensa a necessidade de servidores adicionais. No entanto, em redes que exigem controle mais fino sobre a atribuição de endereços (por exemplo, para registro, auditoria, ou atribuição de DNS), costuma-se combinar o SLAAC com outras soluções, como o DHCPv6.

Configurando o Roteador Cisco

---

Para habilitar o SLAAC em uma rede IPv6 com roteador Cisco, basta configurar o roteador para anunciar prefixos com o flag A (Autonomous) ativado em suas mensagens Router Advertisement (RA). Isso é feito com poucos comandos na interface de rede que conecta ao segmento onde estão os hosts.

Suponha que a rede interna seja 2001:db8:1::/64, e a interface que conecta ao segmento LAN seja GigabitEthernet0/0.

enable
conf t
!
hostname ipv6Router
!
! Habilita IPv6 no roteador
ipv6 unicast-routing
!
interface GigabitEthernet0/0
 ipv6 address 2001:db8:1::1/64
!
! Habilita a geração de Router Advertisements
 ipv6 nd ra interval 30
 ipv6 nd prefix 2001:db8:1::/64 1800 1800
!
! Confirma que o prefixo será anunciado com o flag A (autônomo) ativado
 ipv6 nd prefix default
!
 no shutdown
!
end
wr

• ipv6 unicast-routing: habilita o roteador para encaminhamento IPv6.
• ipv6 address: define o endereço da interface.
• ipv6 nd prefix: anuncia o prefixo com o flag A ativado.
• ipv6 nd ra interval: define o intervalo dos anúncios RA.
• ipv6 nd prefix default: indica que o prefixo deve ser usado para autoconfiguração.

Depois de configurado, os hosts conectados à interface GigabitEthernet0/0 devem autoconfigurar um endereço IPv6 baseado no prefixo anunciado, sem necessidade de DHCPv6. No roteador, você pode verificar com:

show ipv6 interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::5200:FF:FE04:0 
  No Virtual link-local address(es):
  Global unicast address(es):
    2001:DB8:1::1, subnet is 2001:DB8:1::/64 
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:1
    FF02::1:FF04:0
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ICMP unreachables are sent
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds (using 30000)
  ND advertised reachable time is 0 (unspecified)
  ND advertised retransmit interval is 0 (unspecified)
  ND router advertisements are sent every 30 seconds
  ND router advertisements live for 1800 seconds
  ND advertised default router preference is Medium
  Hosts use stateless autoconfig for addresses.

E nos hosts Linux, por exemplo, com:

$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enp0s3
    altname ens3
    inet6 2001:db8:1:0:250:ff:fe00:100/64 scope global dynamic mngtmpaddr 
       valid_lft 1773sec preferred_lft 1773sec
    inet6 fe80::250:ff:fe00:100/64 scope link 
       valid_lft forever preferred_lft forever

Configurando um Linux para atuar como Gateway IPv6

---

Se você não tiver um roteador que suporte SLAAC ou mesmo IPv6 em geral, você pode perfeitamente usar um Linux como gateway IPv6. Ele pode anunciar prefixos via Router Advertisement e encaminhar pacotes entre redes, exatamente como um roteador faria.

No sistema que atuará como roteador/gateway, ative o forwarding:

sudo sysctl -w net.ipv6.conf.all.forwarding=1

Para tornar isso permanente:

echo "net.ipv6.conf.all.forwarding=1" | sudo tee -a /etc/sysctl.conf

Agora você precisa de um serviço que envie Router Advertisements. O mais comum é o radvd (Router Advertisement Daemon). Instale usando o comando abaixo:

sudo apt install radvd

Edite o arquivo de configuração /etc/radvd.conf. Exemplo mínimo:

interface eth0
{
    AdvSendAdvert on;
    prefix 2001:db8:1::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
    };
};

Na interface eth0, envie RAs com o prefixo 2001:db8:1::/64, ativando as flags A (SLAAC) e L (on-link). Depois, inicie o serviço:

sudo systemctl enable --now radvd

Você também precisa dar ao Linux-gateway um endereço dentro da sub-rede:

sudo ip -6 addr add 2001:db8:1::1/64 dev eth0

Os hosts conectados à mesma LAN vão passar a receber RAs do seu Linux e autoconfigurar endereços IPv6 via SLAAC. Se você também tiver outra interface (ex: eth1) conectada à Internet (ou outro link), o Linux poderá rotear pacotes entre as redes, funcionando como gateway completo.

Default Gateway

---

No IPv6, o conceito de gateway padrão funciona de forma diferente do que estamos acostumados no IPv4. Quando um host precisa encaminhar pacotes para fora da sua rede local, ele utiliza um roteador como default gateway, até aí, tudo bem. A diferença é que, em vez de usar o endereço global do roteador como next-hop, o IPv6 adota o endereço link-local como referência para esse roteamento.

Isso acontece porque os roteadores, ao enviarem mensagens de Router Advertisement (RA) para os hosts da rede, anunciam seus prefixos globais (como 2001:db8:1::/64), mas a informação sobre quem é o gateway padrão vem de forma implícita, baseada no endereço de origem da própria RA. E esse endereço de origem é justamente o link-local do roteador, algo como fe80::1.

Esse comportamento é proposital e está alinhado com o modelo de operação do IPv6, que exige que todas as interfaces tenham um endereço link-local, independentemente de haver ou não conectividade global. A escolha do link-local como next-hop tem uma vantagem prática, ele é sempre único e válido apenas dentro daquele segmento de rede, garantindo que o roteamento entre hosts e gateways ocorra corretamente mesmo se houver múltiplos roteadores com endereços globais semelhantes ou até idênticos em redes distintas.

Na prática, isso significa que, ao configurar rotas em um host ou mesmo em outro roteador, se você quiser usar um gateway que esteja diretamente conectado, deve sempre apontar para o endereço link-local do roteador e especificar a interface de saída. O kernel do sistema operacional precisa saber exatamente por qual interface alcançar aquele link-local, já que esses endereços não têm significado fora do segmento local.

Endereçamento IPv6 Estável e Temporário no Linux

---

Ao contrário do que acontece com o IPv4, onde geralmente um host tem apenas um endereço por interface, no IPv6 é comum (e até esperado) que cada interface de rede tenha múltiplos endereços. No Linux, esse comportamento padrão é resultado da combinação do SLAAC com duas RFCs importantes: a RFC 7217, que define o uso de identificadores estáveis, e a RFC 4941, que introduz os endereços temporários.

Quando um roteador envia um prefixo IPv6 válido via SLAAC, como por exemplo 2001:db8:1a45:1e58::/64, o host Linux utiliza esse prefixo para gerar seus próprios endereços IPv6. O primeiro tipo gerado é o chamado endereço "estável". Ele recebe a marcação dynamic mngtmpaddr e é construído com base em um identificador estável que não depende diretamente do endereço MAC, evitando a exposição da identidade física do dispositivo. Esse endereço é geralmente mantido por longos períodos e é usado como destino, ou seja, para receber conexões de entrada, como em servidores ou conexões P2P.

Além dele, o Linux também gera automaticamente um segundo endereço, marcado como temporary dynamic, utilizando a funcionalidade de Privacy Extensions. Esse endereço muda periodicamente e serve para estabelecer conexões de saída com maior privacidade. Em vez de expor um identificador fixo a cada conexão feita pela máquina (como ao navegar na web), o sistema utiliza esse endereço temporário como origem, dificultando o rastreamento da atividade do usuário.

Esses dois tipos de endereços coexistem na mesma interface. O temporário protege a privacidade sem comprometer a estabilidade das conexões entrantes, enquanto o estável garante acessibilidade e previsibilidade dentro da rede. Esse modelo é amplamente adotado por sistemas modernos, especialmente em estações de trabalho, laptops e dispositivos móveis, onde a proteção contra rastreamento é mais crítica.

Configurando IPv6 em rede de pequeno porte

---

Vamos imaginar que recebemos um link de internet com suporte a IPv6, no qual o provedor atribui automaticamente um endereço IPv6 para comunicação direta com a rede dele, e além disso, delega um prefixo para ser utilizado internamente.

A proposta é configurar a interface WAN do roteador com o IPv6 que permite comunicação com o ISP, seja ele atribuído via SLAAC ou manualmente. Já na interface LAN, vamos aplicar o prefixo delegado pelo provedor, de forma que os dispositivos internos da rede possam receber endereços IPv6 válidos via SLAAC e navegar diretamente na internet usando IPv6, com o roteador funcionando como gateway entre os dois domínios.

• G0/1 conectada à WAN (por exemplo, ao seu roteador de operadora).
• G0/0 conectada à LAN, com prefixo 2001:db8:1a45:1e58::/64.
• Os hosts da LAN devem receber IPv6 via SLAAC e conseguir sair para a internet.

Configurando no Cisco

---

Se quiser pegar o IPv6 da WAN via SLAAC:

interface GigabitEthernet0/1
 ipv6 enable
 ipv6 address autoconfig
 no shut

Se preferir configurar manualmente (exemplo):

interface GigabitEthernet0/1
 ipv6 enable
 ipv6 address 2804:7f0:67c8:de67::1/64
 no shut

Agora vamos configurar o prefixo da LAN e ativar o envio de RA:

interface GigabitEthernet0/0
 ipv6 enable
 ipv6 address 2001:db8:1a45:1e58::1/64
 ipv6 nd prefix 2001:db8:1a45:1e58::/64
 ipv6 nd ra interval 30
 ipv6 nd ra lifetime 1800
 no shut

Se quiser simplificar e deixar o roteador anunciar qualquer prefixo configurado:

 ipv6 nd prefix default

Isso é obrigatório para que ele funcione como gateway entre as interfaces:

ipv6 unicast-routing

Se o roteador do provedor anuncia rota default via RA, o seu roteador Cisco pode pegar essa rota via SLAAC na WAN. Para ver, basta usar o comando abaixo:

show ipv6 route

# ou sendo mais direto:
Router#show ipv6 route ::/0
% Route not found

No meu caso não recebi, então vou ter que configurar manualmente:

ipv6 route ::/0 GigabitEthernet0/1 fe80::920a:62ff:fed1:23a0

Aqui o fe80::... é o link-local do roteador da operadora.

Com isso, os hosts conectados à LAN receberão endereços via SLAAC no prefixo 2001:db8:1a45:1e58::/64, e terão como default gateway o endereço link-local do roteador Cisco. O roteador fará o encaminhamento entre LAN e WAN normalmente.

Testando no Linux:

# Pegou IO diretamente no boot do sistema:
alpine:~# ip -6 a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host proto kernel_lo 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:db8:1a45:1e58:bd56:af1a:d825:a571/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591986sec preferred_lft 604786sec
    inet6 fe80::250:ff:fe00:200/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

# Ping para uma máquina na minha rede:
alpine:~# ping -c 5 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530
PING 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530 (2804:7f0:6840:1e58:6d9:f5ff:fe79:4530) 56 data bytes
64 bytes from 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530: icmp_seq=1 ttl=63 time=2.59 ms
64 bytes from 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530: icmp_seq=2 ttl=63 time=2.41 ms
64 bytes from 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530: icmp_seq=3 ttl=63 time=0.878 ms
64 bytes from 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530: icmp_seq=4 ttl=63 time=2.34 ms
64 bytes from 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530: icmp_seq=5 ttl=63 time=2.57 ms

--- 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 0.878/2.157/2.586/0.646 ms

# MTR:
alpine:~# mtr -r -n 2804:7f0:6840:1e58:6d9:f5ff:fe79:4530
Start: 2025-07-19T14:43:59-0300
HOST: alpine                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2001:db8:1a45:1e58::1      0.0%    10    2.7   2.7   1.8   3.2   0.4
  2.|-- 2804:7f0:6840:1e58:6d9:f5  0.0%    10    2.5   2.6   2.2   3.1   0.2

Na minha topologia de teste, configurei um roteador Cisco que tinha uma interface WAN com um IPv6 global obtido via SLAAC (no mesmo prefixo do modem) e uma interface LAN configurada manualmente com um prefixo 2001:db8:1a45:1e58::/64. Os dispositivos internos estavam recebendo endereços SLAAC normalmente a partir desse prefixo e conseguiam enviar pacotes para a Internet sem dificuldade. No entanto, os pacotes de resposta não retornavam, os hosts internos conseguiam sair, mas não recebiam as respostas dos destinos externos.

Depois de verificar que o roteador estava fazendo o encaminhamento corretamente, percebi que o problema estava na ausência de rota de retorno. O modem não sabia que o prefixo 2001:db8:1a45:1e58::/64 estava “atrás” do roteador Cisco, já que esse prefixo não fazia parte do bloco delegado oficialmente pelo provedor. Ou seja, o modem não tinha como encaminhar os pacotes de volta para a rede interna.

Para corrigir esse comportamento, adicionei manualmente uma rota estática em um Linux da minha rede apenas para testar, dizendo explicitamente que qualquer pacote destinado ao prefixo 2001:db8:1a45:1e58::/64 deveria ser encaminhado para o endereço global IPv6 da interface WAN do roteador Cisco, no caso, 2804:7f0:6840:1e58:5200:ff:fe05:1. Isso foi feito com o comando:

sudo ip -6 route add 2001:db8:1a45:1e58::/64 via 2804:7f0:6840:1e58:5200:ff:fe05:1

A partir desse momento, a comunicação se tornou bidirecional. Os pacotes que saíam da LAN e chegavam ao host Linux agora conseguiam retornar para os hosts internos, porque o modem sabia exatamente para onde enviá-los.

Essa etapa é fundamental sempre que se utiliza um prefixo manual que não foi delegado automaticamente pelo ISP, é preciso garantir que o roteador imediatamente acima saiba como alcançar essa rede. Caso contrário, o tráfego será descartado por falta de rota.