Camada de Internet: IP, Endereçamento, Sub-redes e Encaminhamento

O artigo anterior terminou diante de um roteador. Eu, e a esforçada leitora estávamos lá, meio abobados. Porém, já sabemos que ele recebe um quadro (quadro, em português) por uma interface, extrai um pacote IP e escolhe uma saída. Nem tudo está perdido, algo foi aprendido, mas ainda não sabemos como.

Como um roteador decide por qual interface e para qual próximo salto deve encaminhar um pacote?

Esta é uma lacuna perigosa para quem escreve software. A pergunta parece pertencer apenas a um equipamento, mas seus efeitos chegam diretamente ao software. Um serviço pode estar ouvindo na porta correta e permanecer inalcançável porque o prefixo da máquina foi configurado com um bit errado. Um nome pode resolver corretamente e, ainda assim, os pacotes podem seguir para um próximo salto inesperado porque uma rota mais específica venceu. Mensagens pequenas podem atravessar o caminho enquanto mensagens maiores desaparecem porque algum link não comporta o pacote e a origem não recebe a informação necessária para reduzir seu tamanho.

Vamos investigar essa decisão por partes. Primeiro, fixaremos o protocolo IP e localizaremos nos seus cabeçalhos os campos usados para o encaminhamento. Depois, transformaremos endereços em prefixos, acompanharemos a entrega ao primeiro roteador e aplicaremos a correspondência pelo prefixo mais longo. Em seguida, seguiremos uma requisição por um endereço IPv4 público compartilhado e mostraremos como a resposta reencontra a estação privada. Por fim, compararemos IPv4 e IPv6, estudaremos ICMP e a descoberta da MTU do caminho, executaremos a LPM em C++23 e organizaremos um procedimento de auditoria. O Artigo 4 poderá então acrescentar confiabilidade, ordem e controle de congestionamento sobre uma camada cujo comportamento terá perdido o mistério.

Este é o momento de sorrir otimisticamente e respirar fundo.

Antes de consultar qualquer tabela de bits em cabeçalhos, precisamos estabelecer o que o IP promete.

1. O IP promete uma tentativa, não a entrega

O Protocolo de Internet, ou IP, de Internet Protocol, transporta datagramas que carregam endereços de origem e destino de tamanho fixo. Um endereço IPv4 possui $32$ bits. Um endereço IPv6 possui $128$ bits. Ao receber um datagrama, o roteador examina o destino, consulta sua informação de encaminhamento e tenta aproximar o pacote da rede correspondente.

O verbo tenta sustenta o processo inteiro.

O contrato que define esse processo recebe o nome de best effort (melhor esforço). Para entender, primeiro a atenta leitora precisa saber que o protocolo IP não confirma a entrega de qualquer pacote, não recupera uma perda, não preserva a ordem, não elimina duplicatas e não controla a taxa do remetente. Se um roteador detectar determinadas condições, poderá enviar uma mensagem usando o protocolo ICMP para explicar o descarte ou outra dificuldade. A mensagem ICMP também será transportada por IP, portanto também poderá perder-se, ser filtrada ou sofrer limitação de taxa.

No IPv4, um checksum protege apenas o cabeçalho.

O que é um checksum? Um checksum, de forma geral, é um pequeno valor matemático calculado a partir de um bloco de dados, como o cabeçalho de um pacote IPv4, e anexado a ele. O objetivo desse mecanismo é detectar erros ocorridos durante a transmissão pela rede.

O mecanismo funciona de maneira direta. O remetente calcula esse valor a partir dos campos do cabeçalho, e cada equipamento que verifica esse checksum pode detectar alterações ocorridas desde o cálculo anterior. Se a verificação falhar, o cabeçalho foi alterado de uma forma detectável por algum problema na camada de enlace, e o pacote é descartado.

Se a verificação passar, sabemos apenas que o checksum não encontrou uma diferença. Isso não constitui uma prova matemática de integridade, porque alterações distintas em pontos diferentes podem produzir o mesmo resultado. No IPv4, há ainda outro limite: o payload não participa dessa verificação. O checksum checa apenas o cabeçalho.

Como o TTL se altera em cada salto, o roteador deve atualizar o checksum do cabeçalho IPv4 a cada encaminhamento. No IPv6, o checksum foi removido do cabeçalho base, transferindo a responsabilidade pela detecção de erros para a camada de enlace, que já protege o quadro, e para os protocolos de transporte, como TCP e UDP, cada qual com seu próprio mecanismo de integridade. Essa separação elimina o processamento do checksum em cada roteador e reforça a simplicidade do serviço best effort do IP.

Essa simplicidade, quase pobreza, é uma escolha arquitetural.

A camada de Internet precisa atravessar Ethernet, Wi-Fi, fibras de operadora, redes móveis, túneis e tecnologias que ainda não existiam quando o IPv4 foi publicado e não existem hoje. Como o IP separa a resposabilidade do encaminhamento da tecnologia de cada enlace, podemos substituir o meio e os equipamentos sem obrigar todas as aplicações a adotar outro protocolo de Internet. Se a atenta leitora olhar com cuidado há de concordar que esta simplicidade é genial.

A evolução física e a permanência do TCP/IP

Em 1973, Robert Kahn e Vint Cerf começaram a detalhar um protocolo capaz de interligar redes de projetos diferentes. A primeira descrição publicada, em 1974, ainda reunia em um mesmo protocolo funções que depois seriam separadas. A reorganização preservou no IP o serviço simples de endereçamento e encaminhamento de datagramas, enquanto o TCP assumiu funções como controle de fluxo e recuperação de perdas.

A escala física mudou radicalmente. O projeto inicial da ARPANET considerou links de $50\ \text{kbps}$. Hoje, o mesmo IP atravessa redes locais de múltiplos gigabits, links de rádio, redes móveis, fibras submarinas e túneis construídos sobre outras redes. A tecnologia física de hoje era praticamente ficção científica nos anos 1970. A história escrita por participantes desse processo registra tanto a diversidade das redes originais quanto a decisão de conectá-las por uma arquitetura aberta.

O segredo da longevidade do TCP/IP é a sua arquitetura em camadas e o isolamento de funções. O IP não precisa entender as modulações de rádio ou os pulsos de laser em uma fibra óptica. Seu trabalho é organizar e endereçar a informação, entregando o datagrama à camada de enlace e à tecnologia física disponíveis. Cada tecnologia de enlace pode resolver a entrega local de sua maneira, enquanto o IP conserva uma interface lógica comum entre elas. Isso permitiu que o hardware de rede fosse reinventado diversas vezes ao longo das décadas, mantendo a mesma base lógica da Internet.

Antes de prosseguirmos, é preciso separar três conceitos fundamentais que atuam na camada IP; o nome tal como api.example.com é o identificador simbólico que a aplicação conhece. Cabe ao DNS traduzi-lo em um ou mais endereços; o endereço, como 192.0.2.130 para o IPv4, é o que de fato ocupa os campos do cabeçalho IP; dependendo de seu tipo, ele pode designar uma interface específica (unicast), um conjunto de interfaces (multicast) ou uma dentre várias interfaces alternativas (anycast); e a rota que não é um mapa do destino final, mas uma instrução estritamente local. A rota associa um prefixo a uma interface de saída e a um próximo salto, dizendo apenas como dar o próximo passo, sem descrever o caminho completo.

Não esqueça: nome, endereço e rota respondem a perguntas diferentes.

O roteador não encaminha o texto de um nome de domínio. O roteador encaminha um pacote de dados cujo cabeçalho contém um endereço IP de destino. Na Seção 7, retomaremos a hierarquia do DNS e veremos exatamente em que ponto o nome deixa de participar da decisão IP. Antes disso, precisamos entender os campos que viajam nos cabeçalhos IPv4 e IPv6.

2. O que viaja nos cabeçalhos IPv4 e IPv6

Quando a camada de Internet recebe dados de um protocolo como TCP, UDP ou ICMP, ela coloca diante deles um cabeçalho, header em inglês. Esse cabeçalho reúne os metadados de que hosts e roteadores precisam para interpretar e encaminhar o datagrama. Tudo o que vem depois dele é o payload do IP, isto é, os dados transportados pelo protocolo. Esse payload pode conter um cabeçalho TCP, UDP ou ICMP e, somente depois, os dados da aplicação. Portanto, payload do IP e dados da aplicação não são sinônimos.

Neste artigo, usaremos o termo host para representar um dispositivo de rede, como um notebook ou uma televisão.

O tamanho do cabeçalho importa porque o receptor precisa saber em qual byte a carga começa e, principalmente, porque cada byte gasto com metadados deixa um byte a menos para a carga dentro do limite imposto pela MTU. É por isso que não basta decorar que o IPv4 usa $20$ bytes e o IPv6 usa $40$. A atenta leitora precisa entender a origem desses números e o que acontece quando aparece alguma informação opcional.

A Figura 1 preserva a estrutura do cabeçalho em palavras de $32$ bits. No lado IPv4, as cinco primeiras linhas formam os $20$ bytes obrigatórios, e a linha tracejada representa a área variável. No lado IPv6, as dez linhas formam os $40$ bytes fixos. As duas linhas de $128$ bytes na Figura 1 são, na verdade, dois conjuntos de 4 linhas de $32$ bytes Qualquer extensão aparece depois delas.

Figura 1: o IPv4 combina uma parte obrigatória de cinco palavras com uma área opcional. O IPv6 fixa o cabeçalho base em dez palavras e encadeia informações adicionais depois dele.

2.1 De onde vêm os 20 bytes do IPv4

O cabeçalho IPv4 foi desenhado em linhas de $32$ bits, também chamadas de palavras de 32 bits. Como cada byte tem $8$ bits, cada linha ocupa $32/8=4$ bytes . A parte obrigatória do cabeçalho possui cinco dessas linhas:

A soma das larguras confirma o tamanho mínimo:

Os primeiros $4$ bits indicam a versão. Os $4$ bits seguintes formam o IHL, de Internet Header Length (comprimento do cabeçalho Internet). O IHL não guarda uma quantidade de bytes . O IHL guarda uma quantidade de palavras de $32$ bits. O menor valor válido é $5$, porque os campos obrigatórios ocupam cinco palavras. Assim,

Como o IHL possui $4$ bits, seu maior valor é $15$. O maior cabeçalho IPv4 possível ocupa, portanto,

Os $40$ bytes entre o mínimo de $20$ e o máximo de $60$ existem para acomodar as opções do protocolo IP e o preenchimento necessário para terminar o cabeçalho a cada fronteira de $32$ bits. O próprio IHL informa ao receptor onde esse cabeçalho variável termina e onde começa o payload.

A primeira palavra do cabeçalho reserva $8$ bits que, no projeto original do IPv4, chamavam-se tipo de serviço. Hoje, esse espaço está dividido entre o DSCP e o ECN. O DSCP permite que políticas de rede classifiquem o pacote para receber tratamento diferenciado, mas essa classificação não se traduz em uma garantia de qualidade ou de entrega, é apenas uma orientação. O ECN, por outro lado, exige um pouco mais. Quando os extremos e todos os roteadores do caminho cooperam, o ECN torna o congestionamento visível ao remetente sem que o roteador precise descartar o pacote para avisá-lo.

A primeira palavra do cabeçalho ainda guarda o comprimento total, um campo de $16$ bits que não se limita à carga útil mede o datagrama IPv4 inteiro, englobando a parte fixa do cabeçalho, as opções, quando presentes, e o payload propriamente dito. Esse valor é essencial para o receptor, pois, como o cabeçalho pode variar de tamanho graças às opções, é ele quem diz exatamente onde o cabeçalho termina e os dados começam; além disso, ele será a base da nossa conversa sobre MTU na Seção 9. A segunda palavra é dedicada à fragmentação. Nesta palavra residem os campos de identificação, flags e deslocamento, que, embora tratemos com calma adiante, já adiantam o mecanismo pelo qual um roteador pode fatiar um datagrama grande para adaptá-lo a enlaces menores que existam no caminho.

A terceira palavra concentra três informações que governam a travessia do pacote: o TTL, que perde uma unidade a cada salto e, ao chegar a zero, decreta o fim do datagrama; o campo protocolo, que identifica o que vem a seguir na carga, seja TCP, UDP ou ICMP; e o checksum, que protege apenas o cabeçalho e, justamente por depender do TTL, precisa ser recalculado a cada nó, uma das razões pelas quais o IPv6 simplesmente o eliminou. Por fim, as duas últimas palavras da parte fixa, totalizando $8$ bytes, carregam os endereços IPv4 de origem e destino, a informação central que alimenta a decisão de encaminhamento em cada roteador ao longo da rota.

E assim caminha a internet. Mas, espere. Eu falei alguma coisa sobre opções?

2.2 Que opções são essas

Uma opção IPv4 é uma informação adicional colocada dentro do próprio cabeçalho, depois do endereço de destino e antes da carga. Ela não é uma opção de configuração da aplicação nem um campo do TCP ou do UDP. É parte do datagrama IP e, por isso, aumenta o valor do IHL.

A especificação original do IPv4 definiu, entre outras, as seguintes opções:

• Record Route (registro de rota): reserva espaço para que roteadores participantes registrem seus endereços enquanto o datagrama avança. O espaço máximo de opções é pequeno, portanto ela não consegue registrar arbitrariamente um caminho longo;

• Internet Timestamp (marca de tempo da Internet): permite registrar marcas de tempo e, conforme o formato escolhido, endereços dos roteadores participantes;

• Loose Source Route e Strict Source Route (roteamento pela origem flexível e estrito): permitem que a origem forneça informações sobre o caminho a percorrer. Esse poder também cria implicações de segurança e explica por que opções de roteamento pela origem são tratadas com cautela nas redes atuais.

Algumas opções ocupam apenas um byte . Muitas seguem a forma tipo, comprimento e dados. Se o conjunto não terminar em uma fronteira de $32$ bits, bytes de valor zero são acrescentados como preenchimento. A inclusão de uma opção não carrega uma instrução nova, mas ocupa espaço e entra na contagem do IHL.

Suponha que opções e preenchimento ocupem $12$ bytes . O cabeçalho passará a medir $20+12=32$ bytes , isto é, oito palavras de $32$ bits. O sistema remetente escreverá então $IHL=8$. Se o campo comprimento total indicar $1500$ bytes , a carga IP disponível será

Sem opções, o mesmo datagrama teria $IHL=5$ e deixaria $1500-20=1480$ bytes para a carga IP. Se essa carga começar com um cabeçalho UDP de $8$ bytes , sobrarão $1500-20-8=1472$ bytes para os dados da aplicação. Essa é exatamente a conta que reaparecerá na discussão de MTU da Seção 9.

As opções continuam fazendo parte do formato IPv4, mas não devem ser tratadas como um mecanismo de extensão confiável para aplicações comuns. Muitas opções históricas se tornaram obsoletas ou levantam preocupações de segurança. Roteadores e firewalls podem aplicar políticas diferentes a datagramas que as contenham. O problema não se resume a desempenho. Filtrar todas as opções indiscriminadamente também pode quebrar usos legítimos. Para a engenharia de software, a conclusão prática é não presumir que uma opção IPv4 arbitrária atravessará a Internet da mesma forma que um cabeçalho mínimo.

2.3 Por que o cabeçalho base do IPv6 tem 40 bytes

O IPv6 reorganiza a separação entre o caso comum e as funções opcionais. Seu cabeçalho base não possui IHL porque seu tamanho é fixo. As duas primeiras palavras de $32$ bits ocupam $8$ bytes . A primeira contém versão, classe de tráfego e rótulo de fluxo; enquanto a segunda contém comprimento da carga, próximo cabeçalho e limite de saltos. Depois delas vêm dois endereços de $128$ bits, ou $16$ bytes cada. Logo,

A classe de tráfego de $8$ bits acomoda DSCP e ECN. O rótulo de fluxo, com $20$ bits, permite marcar uma sequência de pacotes relacionados para tratamento como um fluxo. Ele não é uma porta e não substitui os identificadores do TCP ou do UDP. Os $32$ bytes ocupados pelos endereços explicam a maior parte da diferença em relação ao cabeçalho IPv4 mínimo.

Há uma diferença fácil de perder entre os dois campos de comprimento. No IPv4, o comprimento total inclui o cabeçalho IPv4. No IPv6, o comprimento da carga conta tudo o que vem depois dos $40$ bytes do cabeçalho base. Incluíndo cabeçalhos de extensão, cabeçalho do protocolo superior, e dados desse protocolo. Em forma compacta teremos:

Informações opcionais do IPv6 aparecem em cabeçalhos de extensão colocados entre o cabeçalho base e o protocolo superior. O campo próximo cabeçalho identifica o elemento imediatamente seguinte. Se esse elemento também for uma extensão, ele possui seu próprio campo próximo cabeçalho. Surge assim uma cadeia como IPv6 → Hop-by-Hop Options → Routing → Fragment → UDP, embora um pacote comum possa ir diretamente de IPv6 para TCP, UDP ou ICMPv6.

Entre as extensões estão opções salto a salto, opções destinadas apenas aos receptores, informações de roteamento e fragmentação. Em regra, extensões não são processadas nem alteradas por roteadores intermediários antes de o pacote alcançar o nó indicado como destino. A exceção é o cabeçalho de opções salto a salto, chamado Hop-by-Hop Options, que pode ser examinado ao longo do caminho quando o equipamento estiver configurado para isso. A fragmentação também muda de lugar. No IPv6, somente a origem pode fragmentar e usa um cabeçalho de extensão de fragmentação, chamado Fragment. Roteadores intermediários não fragmentam o pacote.

2.4 Campos que participam do encaminhamento

O campo TTL, de Time to Live (tempo de vida), do IPv4 e o Hop Limit (limite de saltos) do IPv6 cumprem hoje a mesma função operacional. Em um encaminhamento comum, cada roteador reduz o valor em uma unidade. Se o limite chega a zero, o pacote é descartado. O nome TTL preserva uma origem histórica ligada ao tempo. A operação observável nas redes atuais é uma contagem de saltos.

No IPv4, essa alteração do TTL modifica o cabeçalho. Por isso, o roteador precisa atualizar o checksum do cabeçalho antes de encaminhar o datagrama. Esse checksum cobre apenas o cabeçalho IPv4, não sua carga. O IPv6 removeu o campo do cabeçalho base e, com ele, essa atualização a cada salto. A detecção de erros continua nos protocolos de transporte e, conforme a tecnologia, na camada de enlace.

O campo protocolo do IPv4 e o campo próximo cabeçalho do IPv6 dizem quem interpreta o elemento seguinte. O valor pode indicar TCP, UDP, ICMP ou, no IPv6, um cabeçalho de extensão. O último próximo cabeçalho da cadeia identifica o protocolo superior. Portas não pertencem ao IP. As portas aparecem no transporte e só existem se o protocolo carregado definir esse conceito.

Depois de localizar corretamente todos esses campos, o roteador encontra o endereço de destino. Ainda falta, porém, a regra que transforma esse endereço em uma decisão. Manter uma entrada para cada endereço IPv4 exigiria raciocinar sobre até $2^{32}$ destinos individuais. A rede precisa agrupá-los. É esse problema, e não uma preferência por escrever barras depois de endereços, que nos leva ao CIDR.

3. Link, sub-rede e prefixo, por que CIDR existe

O endereço de destino viaja no cabeçalho, mas ele não traz consigo a instrução de onde entregar o pacote. Um roteador não pode guardar uma decisão para cada um dos (2^{32}) endereços IPv4 possíveis, nem um host pode decorar se cada destino está ou não ao seu alcance direto. Precisamos de uma forma de agrupar endereços — e é aí que entra o prefixo. O prefixo transforma a pergunta para qual endereço? em a qual conjunto este endereço pertence?, permitindo que uma única rota atenda a milhões de destinos e que um host decida, de uma só vez, se o destinatário está no mesmo ambiente local ou se exige a mediação de um roteador.

Essa divisão por prefixos, formalizada pelo CIDR, resolve dois problemas ao mesmo tempo: no núcleo da rede, ela permite agregar rotas e reduzir o tamanho das tabelas de encaminhamento; nas bordas, ela define até onde um host pode alcançar sem sair do seu próprio enlace. Mas há uma armadilha conceitual que precisamos desfazer antes de calcular máscaras. A fronteira matemática do prefixo (sub-rede) e o alcance físico da entrega local (link) são entidades distintas. A primeira pertence à camada de Internet e organiza o espaço de endereçamento. A segunda pertence à camada de enlace e descreve quem consegue se comunicar sem a intervenção de um roteador. Elas costumam estar alinhadas na configuração, mas não são a mesma coisa. Confundir essas duas fronteiras é o caminho mais curto para um diagnóstico equivocado> É exatamente essa distinção que a Seção 3.1 vai esclarecer antes de colocarmos a mão na aritmética dos bits.

3.1 Link e sub-rede descrevem fronteiras diferentes

Antes que a curiosa leitora possa mergulhar na decisão de encaminhamento do protocolo IP, precisamos definir o território da entrega direta. Na pilha TCP/IP que adotamos, as quatro camadas são link, Internet, transporte e aplicação. A camada de enlace reúne as tecnologias que transportam quadros, ou quadros, entre interfaces capazes de se comunicar sem que o pacote atravesse um roteador.

Sem que o pacote atravesse um roteador é a parte importante desta história.

Uma conexão ponto a ponto forma um enlace, ou link em inglês, uma rede Wi-Fi também pode formar um, e vários segmentos Ethernet unidos por switches podem participar do mesmo enlace. Aqui é importante que a leitora entenda que o switch estende a entrega naquele enlace, enquanto o roteador conecta enlaces diferentes e decide quando um pacote deve passar de um para outro.

Um enlace não é sinônimo de cabo, de caminho ou de sub-rede.

Um enlace pode abranger mais de um trecho físico. Além disso, um caminho entre origem e destino pode atravessar vários enlaces. Enlace é um conceito que é defindo pela ligação e pela análise.

A sub-rede, que definiremos a seguir, organiza endereços na camada de Internet, enquanto o enlace descreve o alcance da entrega local na camada de rede. Essa diferença será essencial para entender por que um host procura alguns destinos diretamente e entrega outros a um roteador. A Figura 2 mostra também que cada interface de um roteador participa de um link distinto.

Figura 2: o meio e a quantidade de segmentos podem mudar sem criar outro enlace. Atravessar um roteador encerra uma entrega de link e inicia outra.

Depois de ler o cabeçalho, um host ou um roteador conhece o endereço de destino, mas esse endereço ainda não informa onde o destino pode ser alcançado.

Redes são complicadas e podem ter topologias complexas.

O host precisa decidir se entrega o pacote diretamente no enlace atual ou se o envia a um roteador. O roteador, por sua vez, precisa saber quais destinos podem compartilhar a mesma decisão de encaminhamento.

Sem uma divisão entre a parte comum e a parte variável do endereço, restariam duas alternativas ruins: manter uma decisão para cada endereço individual; ou tratar um conjunto excessivamente grande como se todos os seus membros estivessem no mesmo enlace. Precisamos de um agrupamento explícito que separe destinos locais daqueles que exigem roteamento.

Vamos tornar o problema concreto. Vamos considerar uma organização com sessenta interfaces distribuídas entre três enlaces locais: estações de trabalho, servidores e um laboratório. Quando uma estação envia um pacote a um servidor, o roteador que conecta os dois enlaces precisa receber esse pacote. Se a configuração fizer a estação acreditar que o endereço do servidor pertence ao mesmo bloco local, ela não procurará o roteador, mas tentará encontrar o servidor diretamente em seu próprio enlace. A procura local se repetirá, mas o pacote nem sequer chegará ao equipamento capaz de encaminhá-lo. Na Seção 4 veremos que, no IPv4, esse erro aparece como requisições ARP sem resposta.

Poderíamos evitar essa falha mantendo todas as sessenta interfaces no mesmo enlace. A entrega local funcionaria, mas, no IPv4, cada broadcast ARP alcançaria um conjunto maior de máquinas, e não haveria entre os três grupos uma fronteira de roteamento na qual aplicar decisões distintas da camada de Internet. Esse problema cresce junto com a organização. Uma rede plana acopla mais interfaces ao mesmo espaço de falha e à mesma política de encaminhamento.

É nesse ponto que precisamos da sub-rede.

Uma sub-rede é um bloco de endereços IP que a configuração associa a uma fronteira de entrega local. Seus endereços compartilham uma sequência inicial de bits, o prefixo, enquanto os bits finais distinguem as interfaces dentro do bloco. Um destino que pertence ao prefixo local pode ser procurado no próprio enlace. Um destino que não pertence precisa ser entregue a um roteador.

Enlace e sub-rede participam da mesma decisão sem representar o mesmo objeto.

Em uma configuração comum, uma sub-rede corresponde a um espaço de entrega local. A equivalência, porém, não é uma lei. Um mesmo enlace pode transportar mais de uma sub-rede IP, e uma VLAN pode separar espaços de entrega na camada de enlace. Prefixo e VLAN precisam ser configurados de forma coerente com a topologia, mas nenhum deles cria, por si só, uma política de segurança.

Onde a VLAN entra nessa história?

Uma VLAN, de Virtual Local Area Network (rede local virtual, em português), cria espaços lógicos de entrega sobre uma infraestrutura física compartilhada. Imagine trinta computadores conectados ao mesmo switcher. Sem a separação lógica, os trinta participam do mesmo domínio de broadcast. Com uma VLAN para as quinze máquinas da coordenação e outra para as quinze máquinas de um laboratório, o switcher trata os dois grupos como domínios distintos.

O padrão IEEE 802.1Q define a operação de bridges (pontes em português) e VLANs. Em enlaces que transportam mais de uma VLAN, uma tag pode identificar a qual delas o quadro pertence. Portas de acesso podem entregar o quadro sem essa tag ao dispositivo final, enquanto o switcher conserva internamente a associação com a VLAN configurada. Portanto, não devemos imaginar que todo host necessariamente enxerga a tag.

Compreender VLANs é importante para quem projeta software. Na indústria, servidores de banco de dados de produção podem ficar em VLANs separadas da rede usada pelas estações de trabalho dos desenvolvedores. A separação cria uma fronteira na qual aplicar políticas, mas a segurança ainda depende das regras que controlam a comunicação entre os grupos. Tecnologias de virtualização e implantação de software também podem construir redes virtuais com espaços de entrega separados sobre uma infraestrutura física compartilhada.

Se 10.0.1.5 está em outra VLAN e em outra sub-rede, um ping não atravessa diretamente a camada de enlace entre os grupos. A estação entrega o pacote ao gateway padrão. O roteador, ou um switcher com função de camada 3, decide se existe rota e se a política permite a comunicação. VLAN, sub-rede e regra de filtragem são três objetos relacionados, mas diferentes. O artigo anterior desenvolveu a entrega por switcher e os domínios de broadcast.

A divisão em sub-redes também resolve um problema de escala.

Dentro da organização, um bloco recebido pode ser repartido em sub-redes para estações, servidores e laboratórios. Fora dela, os roteadores não precisam manter uma rota para cada interface nem, necessariamente, uma rota para cada sub-rede interna. Quando os blocos são contíguos e alinhados, podem ser reunidos em um anúncio agregado segundo uma regra simples: todo endereço que começa com estes _bits_ segue por aqui. O mesmo prefixo que separa decisões no interior permite resumi-las no exterior.

O CIDR, de Classless Inter-Domain Routing (roteamento entre domínios sem classes), tornou explícita essa organização por prefixos de comprimento variável. Antes dele, as classes históricas A, B e C fixavam poucas fronteiras possíveis e frequentemente ofereciam blocos pequenos demais ou grandes demais. Com CIDR, um comprimento como /19, /26 ou /31 informa exatamente quantos bits iniciais são significativos. As classes continuam aparecendo em material antigo, mas não são necessárias para calcular, dividir, agregar nem encaminhar os prefixos atuais. A RFC 4632 consolida o endereçamento e a agregação sem classes.

A barra não é um enfeite do endereço. Ela determina o tamanho do conjunto ao qual a rota se aplica.

3.2 A fronteira entre prefixo e identificador

Um endereço IPv4 como 192.0.2.130 é uma forma decimal de escrever $32$ bits, divididos em quatro grupos de oito bits chamados octetos, ou bytes. Muito bom para analistas de redes humanos.

Sozinho, o endereço identifica um ponto no espaço IPv4, mas não revela onde termina o prefixo. Quando escrevemos 192.0.2.130/26, o número $26$ declara que os primeiros $26$ bits formam o prefixo e que os $32-26=6$ bits finais variam dentro do bloco. Este bloco poderá ter $2^6=64$ nós de rede IP.

O /26 define um conjunto, os $6$ bits finais definem um elemento deste conjunto.

Vamos converter apenas o último byte de 192.0.2.130, porque os três primeiros já fornecem $24$ bits completos. O número decimal $130$ será escrito em binário como

O /26 precisa conservar mais dois bits desse byte . Portanto, a fronteira será:

Todos os endereços que começam com os mesmos $26$ bits pertencem ao mesmo bloco, o mesmo conjunto de endereços. Os seis bits finais podem assumir $2^6=64$ combinações, $64$ elementos do conjunto, cujos identificadores variam de 000000 a 111111. Observe que já conseguimos contar o tamanho do bloco antes mesmo de falar em máscara. Máscara?

3.3 A máscara transforma a fronteira em uma operação

Precisamos agora de uma forma mecânica de apagar a parte variável e conservar apenas o prefixo. A máscara de sub-rede faz isso usando $1$ nos bits que devem permanecer e $0$ nos bits que devem ser zerados. Para um comprimento $p$, a máscara IPv4 será formada por $p$ bits iguais a $1$, seguidos de $32-p$ bits iguais a $0$. Só para lembrar: o endereço IP tem $32$ bits.

Para o /26, a máscara terá $26$ uns e $6$ zeros, totalizando os $32$ bits possíveis. Sendo assim, teremos:

Ou seja, a notação /26 e a máscara 255.255.255.192 descrevem a mesma fronteira.

A primeira notação é compacta e serve tanto ao IPv4 quanto ao IPv6. A segunda notação torna visível a operação tradicional do IPv4 e é comum em livros de rede canônicos. Uma máscara de prefixo válida, no entanto, precisa obedecer a uma regra estrutural: todos os $1$s devem estar contíguos à esquerda, formando um único bloco que define quantos bits do endereço são fixos; todos os $0$s, por sua vez, devem estar contíguos à direita, indicando os bits que podem variar. Essa contiguidade é o que garante que o prefixo descreva um conjunto de endereços contíguo, uma exigência fundamental do CIDR.

Um padrão como 11110011 quebra essa regra: ele mistura $1$s e $0$s, preservando os quatro primeiros bits do octeto e também os dois últimos bits, mas descartando exatamente os dois bits centrais. O resultado seria um conjunto de endereços espalhado em quatro pedaços distintos dentro do mesmo octeto, algo que nenhuma barra / consegue expressar como um único bloco de $n$ bits iniciais. Por isso, o padrão 11110011 não descreve um prefixo CIDR válido.

Para obter o endereço de rede, isto é, a forma canônica que nomeia o bloco, fazemos um E lógico entre o endereço e a máscara. A operação E lógico produzirá $1$ somente quando os dois bits de entrada são $1$, por isso a máscara conserva o prefixo e zera a parte variável. No último byte do endereço teremos,

Ou em representação decimal:

Logo, o endereço 192.0.2.130/26 pertence à rede 192.0.2.128/26. A conta completa não adivinha o intervalo decimal. Ela simplesmente demonstra que os primeiros $26$ bits coincidem.

Para encontrar o outro extremo, mantemos os bits do prefixo e colocamos $1$ em todos os seis bits variáveis. O último byte passa de 10000000 para 10111111, isto é, de $128$ para $191$. O bloco completo irá de 192.0.2.128 a 192.0.2.191.

No uso tradicional de uma sub-rede IPv4, o primeiro endereço nomeia a rede e o último é o broadcast dirigido daquele prefixo. Logo, removendo o endereço que nomeia a rede eo endereço de broadcast, os endereços atribuíveis a interfaces vão de 192.0.2.129 a 192.0.2.190, totalizando $64-2=62$. O endereço 192.0.2.130 é apenas um exemplo de membro desse conjunto. A rede é o bloco inteiro.

A Figura 3 apresenta essa fronteira. Os dois primeiros bits do último byte permanecem fixos, enquanto os seis seguintes podem variar. A representação decimal de $130$ não decide a rede. Quem decide é o binário.

Figura 3: a barra /26 fixa os primeiros 26 bits. Todos os endereços que compartilham esses _bits pertencem ao mesmo bloco de 64 endereços._

Há ainda um atalho decimal seguro que a atenta leitora precisa conhecer.

Se considerarmos $h=32-p$ como a quantidade de bits variáveis, o bloco contém $2^h$ endereços. Para /26, $h=6$ e o tamanho será $64$. Os limites possíveis no último byte são, portanto, múltiplos de $64$: $0$, $64$, $128$ e $192$. Como $130$ está entre $128$ e $191$, encontramos o mesmo bloco. O atalho funciona porque nasce do binário. Perder tempo memorizando tabelas sem entender essa origem apenas troca raciocínio por boa memória ou sorte. Pode funcionar em uma avaliação, mas não funcionará em uma carreira.

3.4 Dividir um prefixo em blocos menores

Uma vez fixada a fronteira entre o prefixo e a parte variável, podemos movê-la para criar divisões internas. A operação de subnetting (divisão em sub-redes) consiste justamente em tomar um bloco e reparti-lo em pedaços menores, cada um com seu próprio prefixo. Para enxergar como isso funciona, imagine que partimos de um /24, um bloco que já tem os primeiros $24$ bits fixos e deixa $32-24=8$ bits livres para identificar interfaces, totalizando $2^8=256$ endereços. Se avançarmos a fronteira para /27, estaremos “pegando emprestados” $27-24=3$ bits que antes pertenciam à parte variável e os transformando em parte fixa do prefixo. Esses três bits emprestados agora distinguem sub-redes diferentes: como cada um deles pode ser $0$ ou $1$, as combinações possíveis são $2^3=8$, ou seja, surgem oito prefixos /27 dentro do bloco original. Cada um desses novos prefixos, por sua vez, deixa apenas $32-27=5$ bits para a parte variável, o que significa que cada sub-rede contém $2^5=32$ endereços.

Essa troca de mais sub-redes com menos endereços por sub-rede é o coração do subnetting, e ela pode ser lida diretamente na diferença entre os comprimentos dos prefixos. Os $3$ bits que acrescentamos ao prefixo não desaparecem; eles simplesmente mudam de função. Antes serviam para numerar hosts dentro de um único bloco grande, agora servem para numerar sub-redes dentro daquele mesmo espaço. Por isso, o número de sub-redes cresce exponencialmente com a quantidade de bits emprestados ($2^3=8$), enquanto o tamanho de cada sub-rede encolhe na mesma proporção ($2^5=32$). A beleza da aritmética binária é que uma única mudança na barra explica simultaneamente as duas faces da moeda: quantos blocos criamos e quantos endereços cabem em cada um.

3.5 Reunir prefixos exige contiguidade e alinhamento

O que é um anúncio de rota?

Um anúncio de rota é uma mensagem de controle que um roteador envia a seus vizinhos para declarar: “eu sei como alcançar este prefixo”. Esse anúncio não carrega dados de usuário; sua função é alimentar as tabelas de encaminhamento dos demais roteadores, construindo o mapa distribuído que orienta o tráfego pela Internet. Ao receber um anúncio, um roteador aprende que, para chegar àquele prefixo, deve entregar o pacote ao roteador que o anunciou. O anúncio representa, portanto, uma promessa de alcançabilidade. O equipamento está dizendo “mande esse tráfego para mim”, mas o anúncio não garante que cada sub-rede interna esteja ativa nem que cada pacote chegará ao destino final. No contexto da agregação,resumir vários prefixos em um único anúncio menos específico reduz a quantidade de promessas que os roteadores precisam memorizar, economizando memória e acelerando o encaminhamento.

O caminho inverso da divisão é a agregação de rotas, que reúne prefixos contíguos em um anúncio menos específico, reduzindo o número de entradas que os roteadores vizinhos precisam manter. Quatro prefixos /24 consomem $4 \times 256 = 1024$ endereços, o que corresponde a $2^{10}$ combinações. Um único prefixo /22 também deixa $32 - 22 = 10$ bits variáveis e, portanto, cobre exatamente $2^{10} = 1024$ endereços. Em termos de tamanho, os quatro /24 caberiam perfeitamente dentro de um /22. Mas, para que a agregação seja válida, o tamanho não é o único requisito: o conjunto precisa começar em uma fronteira que respeite o alinhamento binário exigido pelo prefixo mais curto.

Por que o alinhamento importa? Quando recuamos a fronteira de um /24 para um /22, estamos devolvendo dois bits para a parte variável do endereço. Esses dois bits podem assumir $2^2 = 4$ combinações diferentes, o que significa que um /22 agrupa exatamente quatro blocos /24 consecutivos, mas apenas aqueles cujos terceiros bytes formam uma sequência que começa em um múltiplo de $4$. É por isso que os prefixos de 203.0.112.0/24 a 203.0.115.0/24 podem ser agregados em 203.0.112.0/22: eles são contíguos, e $112$ é múltiplo de $4$. Em binário, os terceiros octetos dessa faixa são:

Os seis bits mais significativos — 011100 — são idênticos em todos os quatro números, exatamente os $22$ bits que o prefixo /22 exige. A sequência seguinte, porém, se estendesse até $116$, já começaria a desalinhar:

Aqui, o sexto bit (contando da esquerda) muda de 0 para 1, rompendo a identidade exigida pelo /22. Se tentássemos agregar os blocos de $113$ a $116$ em um único /22, o prefixo cobriria também endereços que não pertencem aos quatro blocos originais, anunciando alcançabilidade para destinos que o roteador, de fato, não conhece.

A Figura 4 coloca os dois movimentos sobre a mesma régua. Na parte superior, avançar três bits divide o /24 em oito intervalos de $32$ endereços. Na parte inferior, recuar dois bits reúne quatro /24 quando todos compartilham os $22$ bits preservados e cobrem as quatro combinações dos dois bits devolvidos à parte variável. A sequência de $113$ a $116$ cruza uma fronteira /22 e, por isso, não cabe em um único anúncio agregado exato.

Figura 4: avançar a fronteira divide um bloco em partes iguais. Recuá-la só produz um agregado exato quando os prefixos menores começam no alinhamento exigido.

Vamos adiantar um pouco. Essa exigência de alinhamento liga endereçamento e roteamento.

Ao receber o anúncio 203.0.112.0/22, outro roteador passa a encaminhar para o anunciante os pacotes destinados a qualquer endereço entre 203.0.112.0 e 203.0.115.255. O anúncio resume uma decisão de encaminhamento. Ele não verifica se cada interface existe nem acompanha, sozinho, o estado de todas as sub-redes internas.

Imagine que o anunciante alcance três dos quatro /24, mas não possua caminho para 203.0.114.0/24. O destino 203.0.114.7 continua pertencendo matematicamente ao /22 e, por isso, o tráfego externo continuará chegando. O alinhamento garantiu que o resumo descreve o conjunto pretendido. Não garantiu que a configuração interna consiga entregar todos os pacotes recebidos.

Essa lacuna precisa terminar em uma decisão definida. Uma rota de descarte para o agregado descarta o tráfego que não encontra uma rota interna mais específica, evitando que ele escape de volta por outra saída e possa formar um laço. As sub-redes alcançáveis continuam usando suas rotas mais específicas. A Seção 5 mostrará por que essas entradas vencem sem desmontar o agregado e retomará o caso da lacuna em um exercício resolvido.

A fórmula $2^{32-p}-2$, na qual $p$ é o comprimento do prefixo, é o modelo didático canônico para contar endereços atribuíveis quando a rede e o broadcast dirigido ocupam os dois extremos, caso comum até /30. Ela não é uma lei universal. Uma rota /32 seleciona um único endereço. Um link ponto a ponto /31 pode usar seus dois endereços segundo a RFC 3021. O IPv6 não possui broadcast e, portanto, não reserva o último endereço do prefixo para esse papel.

O laboratório seguinte reutiliza 192.0.2.130/26. Altere o prefixo e observe quais bits mudam de papel. Depois escolha um endereço na borda do bloco para testar se sua previsão de rede e broadcast permanece correta.

O laboratório torna visíveis duas grandezas que precisam permanecer ligadas. Cada bit transferido da parte variável para o prefixo dobra a quantidade de blocos e divide por dois o tamanho de cada bloco. Nos casos /31 e /32, a aritmética continua correta, mas a interpretação dos extremos muda. Essa diferença é o motivo para separar o tamanho matemático do conjunto das regras de atribuição de endereços.

A operação de mover a fronteira também vale para os $128$ bits do IPv6. Retomaremos essa aritmética na Seção 8, depois de aprender a ler a representação hexadecimal sem confundi-la com uma mudança do conceito de prefixo.

3.6 Exercícios da Seção 3

1. Calcule rede, broadcast e faixa de um /26

Para 192.0.2.130/26, determine máscara, rede, broadcast, primeiro endereço de host, último endereço de host e quantidade convencional de hosts.

Solução: O comprimento $p=26$ deixa $h=32-26=6$ bits variáveis. O tamanho do bloco será

No último byte , os blocos começam nos múltiplos de $64$: $0$, $64$, $128$ e $192$. Como $130$ pertence ao intervalo fechado de $128$ a $191$, o endereço de rede será .128. O broadcast será o último endereço desse mesmo intervalo, .191. Retirando os dois extremos no uso convencional, obtemos:

O endereço 192.0.2.130 é o segundo endereço atribuível desse bloco, pois 192.0.2.129 é o primeiro. A conta não depende de classes A, B ou C, mas dos $26$ bits fixos e do alinhamento em múltiplos de $64$.

2. Divida um /24 em sub-redes /27

Divida 198.51.100.0/24 em prefixos /27. Quantas sub-redes surgem, quantos endereços cada uma contém e quais são seus endereços de rede?

Solução: A divisão aumenta o prefixo de $24$ para $27$, usando $3$ bits adicionais para distinguir sub-redes. A quantidade de sub-redes será

Cada /27 deixa $32-27=5$ bits de host e contém $2^5=32$ endereços, dos quais $30$ são utilizáveis no modelo convencional. O passo no último byte é $32$:

Os oito blocos são contíguos, não se sobrepõem e recompõem exatamente os $8\times32=256$ endereços do /24. A nova fronteira trocou tamanho por quantidade: obtivemos oito redes, mas cada uma comporta somente trinta endereços atribuíveis no modelo convencional.

3. Escolha o menor prefixo para cinquenta interfaces

Qual o menor bloco IPv4 convencional capaz de acomodar $50$ interfaces, mantendo rede e broadcast?

Solução: Precisamos encontrar $h$, a quantidade de bits variáveis, tal que a contagem convencional, já descontados os endereços de rede e broadcast, acomode cinquenta interfaces:

Com $h=5$, temos $2^5-2=30$, insuficiente. Com $h=6$, temos $2^6-2=62$, suficiente. Vamos comparar as duas escolhas:

O comprimento do prefixo será dado por:

O menor bloco é um /26, com $64$ endereços totais e $62$ atribuíveis. Um /25 serviria, mas reservaria $126$ endereços atribuíveis para uma necessidade de cinquenta. Um /27 ofereceria apenas trinta e não serviria.

4. Verifique se quatro /24 podem ser agregados

Os prefixos 203.0.112.0/24, 203.0.113.0/24, 203.0.114.0/24 e 203.0.115.0/24 podem ser anunciados como um único prefixo? Qual?

Solução: Quatro blocos /24 exigem dois bits adicionais de variação, portanto o agregado candidato será /22. Um /22 começa em múltiplos de quatro no terceiro byte . Como $112/4=28$ sem resto, o início está alinhado. Esse bloco cobrirá os terceiros bytes $112$, $113$, $114$ e $115$.

O agregado será 203.0.112.0/22. Ele contém

endereços, exatamente os $4\times256=1024$ endereços dos quatro /24. Portanto, 203.0.112.0/22 é uma agregação exata. Se a sequência começasse em 203.0.113.0/24, não estaria alinhada em uma fronteira /22. O prefixo candidato incluiria endereços externos ao conjunto e afirmaria uma alcançabilidade que os quatro blocos não demonstram.

4. Do prefixo à primeira entrega: ARP e o gateway padrão

4.1 A tabela de rotas decide entre destino local e roteador

Neste ponto, a atenta leitora já é capaz de calcular o bloco ao qual um endereço pertence. Falta transformar essa conta em uma ação sobre o primeiro link. Quando uma aplicação envia dados, o sistema operacional não entrega o pacote imediatamente a qualquer roteador disponível. Ele consulta as rotas do próprio host para responder a duas perguntas: o destino está em um prefixo alcançável diretamente por alguma interface, ou precisamos entregá-lo a um roteador?

Rota conectada × rota padrão

Uma rota conectada nasce da configuração de uma interface. Ela diz: “todo destino que pertencer a este prefixo está no mesmo link que eu — posso tentar entregá-lo diretamente”. Ela não garante que o destino exista; apenas que, se existir, está ao alcance local.

A rota padrão é uma rota como qualquer outra, com prefixo /0. Ela diz: “para qualquer destino que nenhuma rota mais específica consiga alcançar, entregue a este roteador”. Ela não é um comportamento automático; é uma entrada configurada (ou aprendida) e, como toda rota, perde para qualquer coincidência mais específica.

Uma rota conectada nasce da configuração de uma interface. Se a interface eth0 possui 192.0.2.130/26, o sistema conhece o prefixo conectado 192.0.2.128/26 e sabe que os endereços de 192.0.2.128 a 192.0.2.191 estão no mesmo link, ressalvadas as regras de atribuição dos extremos. Essa rota não diz que todos esses endereços existem. Ela diz que, se um deles existir, pode ser procurado diretamente naquele link.

Vamos comparar dois destinos em uma tabela que contém essa rota conectada e uma rota padrão, sem exceções mais específicas. 192.0.2.150 pertence ao mesmo /26, pois a aplicação da máscara produz 192.0.2.128. A rota conectada vencerá, e a entrega será diretamente no link, isto é, o próprio destino IP será o próximo salto. Já 198.51.100.20 não pertence ao prefixo conectado. A única candidata restante será a rota padrão, cujo próximo salto será o gateway padrão, o roteador configurado como saída do host, por exemplo 192.0.2.129.

Essa decisão produz um endereço IP de próximo salto, mas a Ethernet precisa de um endereço MAC para construir o quadro. Chegamos ao segundo mecanismo.

4.2 ARP resolve um vizinho, não uma rota

A consulta à tabela de rotas já determinou por qual interface o pacote deve sair e qual será o próximo salto. Se o destino 192.0.2.150 pertence ao prefixo conectado 192.0.2.128/26, o próprio destino será o próximo salto. Se o destino for 198.51.100.20, que está fora desse prefixo, a rota disponível poderá indicar 192.0.2.129, o gateway padrão, como próximo salto.

Essa decisão ainda produz um endereço IPv4.

Para realizar a entrega pela Ethernet, o host precisa descobrir qual endereço MAC corresponde ao IPv4 do próximo salto. Esse é o trabalho do ARP, de Address Resolution Protocol (protocolo de resolução de endereços). O ARP não escolhe rotas, não procura caminhos pela Internet e não consulta diretamente um destino remoto. Ele resolve a associação entre um endereço IPv4 alcançável diretamente no link e o endereço MAC usado para alcançar aquele vizinho no link atual.

O processo começa pela consulta ao cache ARP. Se houver uma associação válida para o IPv4 do próximo salto, o host poderá reutilizá-la. Caso contrário, ocorrerá a seguinte sequência:

1. O host cria uma requisição ARP, chamada ARP Request, contendo o endereço IPv4 que deseja resolver.
2. A requisição é enviada em um quadro de broadcast, cujo endereço MAC de destino será FF:FF:FF:FF:FF:FF.
3. As interfaces pertencentes ao mesmo domínio de broadcast recebem a requisição, mas somente a interface associada ao IPv4 procurado deve responder.
4. A resposta, chamada ARP Reply, informa o endereço MAC correspondente e normalmente retorna por unicast ao solicitante.
5. O host registra temporariamente essa associação no cache ARP para reutilizá-la nas próximas transmissões.

A Figura 5 acompanha o caso em que a consulta termina em um cache miss, isto é, não encontra uma associação utilizável. A requisição ARP se ramifica pelo domínio de broadcast, mas a resposta ARP volta apenas da interface proprietária do endereço. Essa resposta transforma a ausência inicial na associação de que a Ethernet precisava.

Figura 5: o _broadcast distribui a pergunta pelo link, mas apenas o proprietário de 192.0.2.150 responde. A origem termina com uma associação ARP válida para o próximo salto._

O endereço consultado pelo ARP depende, portanto, da decisão que a tabela de rotas tomou anteriormente:

No segundo caso, o host não envia uma requisição ARP procurando por 198.51.100.20. Esse endereço identifica o destino final do pacote, mas não uma interface diretamente alcançável no link atual. Além disso, um quadro de broadcast usado pelo ARP permanece no domínio de broadcast em que foi criado e não é encaminhado por roteadores.

ARP resolve o endereço MAC do próximo salto escolhido pela tabela de rotas. Ele não escolhe esse próximo salto.

Essa separação também orienta o diagnóstico. A ausência inicial de uma associação ARP é um cache miss normal e deve provocar a resolução descrita acima. A entrega falha quando essa resolução permanece incompleta ou sem resposta, ou quando uma entrada incorreta aponta para outro endereço MAC. Da mesma forma, uma associação ARP válida não corrige uma rota que escolheu a interface ou o próximo salto errado. A tabela de rotas determina qual vizinho deve receber a próxima entrega. O ARP fornece o endereço MAC necessário para alcançá-lo.

Agora sabemos qual vizinho deverá receber o primeiro quadro. Falta acompanhar o que permanece e o que muda quando esse vizinho é um roteador e o pacote precisa atravessar outro link.

4.3 O quadro termina, o pacote continua

Se o destino for remoto, a origem cria um quadro cujo MAC de destino pertence ao roteador 192.0.2.129, mas conserva 198.51.100.20 como destino no cabeçalho IP. O roteador recebe o quadro, remove o envelope Ethernet, reduz o TTL, atualiza o checksum do cabeçalho IPv4 e consulta sua própria tabela de rotas. Depois, resolve o próximo vizinho e cria outro quadro adequado ao link de saída.

A Figura 6 mostra essa invariante. O endereço IP de destino continua 198.51.100.20 nos dois links. Os endereços MAC mudam de A para R1 e, depois, de R1 para B. O quadro pertence a um link específico, o pacote atravessa vários.

Figura 6: a decisão de sub-rede escolhe de qual host precisamos conhecer o endereço MAC. O destino IP remoto não vira o destino MAC do primeiro quadro.

O prefixo configurado no host participa diretamente dessa decisão. Imagine que 192.0.2.130 seja configurado por engano como /25, embora o link real seja /26. O destino 192.0.2.200 parecerá local ao host, que enviará ARP repetidamente em busca dele. O roteador nunca receberá o pacote, porque o host decidiu não usar o gateway padrão. Um único bit de prefixo errado não produz um erro vago; ele muda o equipamento para o qual a Ethernet tenta entregar o quadro, e o pacote nunca chega ao roteador.

No IPv6, o protocolo de descoberta de vizinhos, ou NDP, de Neighbor Discovery Protocol, ocupa uma fronteira maior. Ele usa mensagens ICMPv6 e multicast para resolver endereços de link, descobrir roteadores e prefixos, testar a alcançabilidade de vizinhos e detectar endereços duplicados. A Seção 8 desenvolverá essas funções. Por enquanto, precisamos conservar a consequência: bloquear ICMPv6 como se fosse telemetria opcional pode impedir a própria entrega local.

4.4 Exercício da Seção 4

1. Explique por que uma rota conectada não elimina ARP

Uma estação possui a rota conectada 192.0.2.128/26 dev eth0 e quer enviar para 192.0.2.150. Por que ainda precisa de ARP?

Solução: A rota responde que o destino está diretamente alcançável por eth0, portanto o próprio 192.0.2.150 será o próximo salto IP. Ela não informa qual endereço MAC deve aparecer no quadro Ethernet.

ARP resolve a segunda associação, de 192.0.2.150 para o endereço MAC da interface de destino. A tabela de rotas escolhe a interface e o próximo salto IP, enquanto o cache ARP fornece o endereço de destino do quadro naquele link. Uma tabela correta não substitui a outra.

Depois que o host entrega o pacote ao primeiro roteador, a pergunta muda. Já não basta decidir entre local e gateway padrão. O roteador pode conhecer várias rotas que contêm o mesmo destino, e precisa escolher entre elas.

5. Correspondência pelo prefixo mais longo

Uma rota não descreve o caminho completo até o destino. Ela associa um prefixo a uma decisão local, normalmente uma interface de saída e um próximo salto. O roteador seguinte repetirá a operação com a própria tabela. A Internet consegue encaminhar sem que nenhum roteador carregue um mapa completo de cada viagem.

O plano de controle aprende ou configura rotas e decide quais alternativas instalar para encaminhamento. O plano de dados consulta a estrutura resultante, frequentemente chamada FIB, de Forwarding Information Base (base de informações de encaminhamento), para cada pacote. Em tabelas pequenas podemos tratá-la como uma lista, mas, em equipamentos reais, estruturas especializadas e hardware aceleram a consulta.

5.1 Quando um prefixo coincide

Seja $D$ o endereço de destino do pacote, $N$ o endereço de rede armazenado na rota e $M_p$ a máscara correspondente ao comprimento $p$. A rota será candidata quando

A igualdade afirma que os primeiros $p$ bits de $D$ são os mesmos do prefixo armazenado. Os bits restantes do destino não participam da comparação. Quanto maior for $p$, menor será o conjunto descrito pela rota.

Várias rotas podem coincidir ao mesmo tempo. A regra de correspondência pelo prefixo mais longo, ou LPM, de Longest Prefix Match, conserva as candidatas e escolhe o maior comprimento de prefixo. Em outras palavras, vence a rota mais específica, aquela que descreve o menor conjunto ainda capaz de conter o destino.

Vamos considerar a tabela:

O destino 198.51.100.140 coincide com as quatro entradas. Ele pertence a toda a Internet representada por /0, ao agregado 198.51.0.0/16, à rede 198.51.100.0/24 e à metade superior dessa rede, 198.51.100.128/25. A /25 vence porque fixa $25$ bits, mais que /24, /16 e /0.

A rota padrão 0.0.0.0/0 merece atenção. Seu comprimento zero não exige coincidência de nenhum bit e sua máscara contém somente zeros. Portanto, para qualquer destino $D$, o resultado de $D\ \operatorname{AND}\ 0$ será $0$, e a rota será candidata. Ela não significa usar apenas quando a tabela está vazia. Significa usar quando nenhuma candidata mais específica vencer.

A rota padrão não é um “se não souber, joga fora”

A rota 0.0.0.0/0 é uma rota legítima, com máscara de todos os zeros. Ela coincide com qualquer endereço porque a operação D AND 0 = 0 é verdadeira para todo D. A LPM a coloca no final da fila, mas ela só é usada quando nenhum prefixo mais longo coincide. Se você remover a rota padrão e não houver outra coincidência, o pacote será descartado — não há um “plano B” mágico no protocolo.

A Figura 7 alinha as quatro coincidências sobre o mesmo endereço. As barras ficam menores à medida que o comprimento aumenta, tornando visível que a escolha da LPM é uma relação entre conjuntos aninhados.

Figura 7: várias rotas podem ser verdadeiras ao mesmo tempo. Vence a que descreve o menor conjunto que ainda contém o destino.

O agregado continua útil porque resume muitos destinos, enquanto a /25 cria uma exceção para apenas metade de um /24. Não há contradição em manter as duas rotas, porque a LPM foi criada justamente para que resumo e exceção coexistam.

5.2 Especificidade primeiro, preferência depois

O comprimento do prefixo e a métrica respondem a perguntas diferentes. A LPM pergunta qual conjunto de destinos descreve melhor este endereço? A métrica ou a preferência pergunta qual alternativa usaremos para o mesmo prefixo? Por isso, uma rota /25 não perde para uma /24 apenas porque a /24 possui uma métrica numericamente menor.

Na prática, o plano de controle pode aprender várias rotas para o mesmo prefixo. Distância administrativa, preferência do protocolo, métrica e política selecionam quais serão instaladas, conforme a implementação. Se alternativas equivalentes permanecerem, o equipamento pode instalar vários próximos saltos e distribuir tráfego por ECMP, de Equal-Cost Multi-Path (múltiplos caminhos de mesmo custo). No plano de dados, porém, a especificidade do destino continua precedendo a comparação entre alternativas do mesmo prefixo.

O Artigo 6 tratará de como os roteadores aprendem rotas e de como políticas entre sistemas autônomos alteram os anúncios. Nesta seção, guardaremos o contrato de encaminhamento: primeiro encontrar todas as coincidências, depois conservar o maior comprimento.

5.3 Laboratório: da coincidência à rota vencedora

No laboratório de rotas, consulte 203.0.113.7, 198.51.7.9, 198.51.100.20 e 198.51.100.140 e observe o conjunto completo de candidatos. Esses mesmos destinos serão resolvidos no Exercício 1 da Seção 5.4. Depois desative a exceção /25 e consulte novamente 198.51.100.140. O destino continua alcançável, mas muda de próximo salto porque a /24 passa a ser a melhor coincidência.

O laboratório separa duas operações que uma resposta pronta costuma esconder. Primeiro, cada linha da tabela produz um resultado verdadeiro ou falso para a coincidência. Depois, somente entre as linhas verdadeiras, escolhemos o maior comprimento. Desabilitar a /25 não torna a /24 mais específica. Apenas remove a candidata que antes vencia.

5.4 Exercícios da Seção 5

1. Escolha a rota para quatro destinos

Use a tabela anterior para os destinos 203.0.113.7, 198.51.7.9, 198.51.100.20 e 198.51.100.140.

Solução: Para cada destino, conservamos apenas os prefixos cujos bits iniciais coincidem e, em seguida, escolhemos o maior comprimento.

A rota padrão coincide com todos os destinos e perde para qualquer entrada mais específica. A tabela evidencia a progressão: conforme o destino entra em conjuntos menores, o próximo salto muda de /0 para /16, depois para /24 e, por fim, para /25.

2. Mostre o limite de uma exceção /25

Qual rota vence para 198.51.100.127 e 198.51.100.128? Explique a mudança.

Solução: O /25 deixa sete bits variáveis, portanto contém $2^7=128$ endereços. Como 198.51.100.128/25 começa em .128, cobre o intervalo de .128 a .255. O endereço .127 está fora da exceção e coincide no máximo com o /24. Seguirá para 192.0.2.150.

O endereço .128 é o primeiro do /25. Ele coincide com a exceção e seguirá para 192.0.2.160. Dois endereços consecutivos tomam rotas diferentes porque a fronteira binária do /25 passa exatamente entre 01111111, que vale $127$, e 10000000, que vale $128$.

3. Determine se um resumo esconde uma ausência

Um roteador anuncia 203.0.112.0/22, mas a sub-rede 203.0.114.0/24 não está conectada em seu interior. O que acontece com pacotes para 203.0.114.7 se não houver uma rota mais específica de descarte?

Solução: O resumo /22 cobre os terceiros bytes de $112$ a $115$, portanto inclui 203.0.114.7. Roteadores externos encaminharão o pacote ao anunciante, pois a rota agregada afirma alcançabilidade para todos os $1024$ endereços do bloco.

Se o roteador interno não possui caminho para o /24 ausente e conserva apenas uma rota padrão que aponta de volta, o pacote pode retornar ao roteador externo. Os dois equipamentos repetirão as próprias decisões até o TTL chegar a zero. A prática segura é instalar uma rota de descarte para o agregado no roteador que o anuncia. Rotas mais específicas válidas vencem essa rota. Lacunas do resumo são descartadas em vez de escaparem por uma rota menos específica.

4. Compare duas rotas de mesmo prefixo

Duas entradas para 198.51.100.0/24 possuem métricas $10$ e $30$, ambas válidas no mesmo protocolo. Qual vence? A resposta mudaria se a rota de métrica $30$ fosse /25 e o destino estivesse dentro dela?

Solução: Com o mesmo /24 e o mesmo protocolo, os dois candidatos descrevem exatamente o mesmo conjunto. Pela hipótese do enunciado, a métrica menor, $10$, vence.

Se a segunda rota fosse /25 e o destino coincidisse com ela, o comprimento seria comparado antes da métrica. A /25 venceria mesmo com métrica $30$, pois descreve uma rota mais específica. Métricas comparam alternativas para o mesmo conjunto, mas não anulam a regra de maior prefixo.

A tabela separa as duas ordens de decisão. Primeiro escolhemos o conjunto de destinos descrito pelo maior prefixo coincidente. Somente entre alternativas para o mesmo conjunto entra a métrica declarada no enunciado.

6. Escopos IPv4 e a necessidade de tradução

Até aqui tratamos cada endereço como um conjunto de bits submetido a prefixos. A interpretação operacional exige mais uma distinção: nem todo endereço de $32$ bits possui o mesmo escopo, isto é, o mesmo território em que conserva significado. Um endereço pode identificar uma interface apenas dentro do próprio host, apenas no link local, dentro de muitas redes privadas ou na Internet pública.

6.1 O alcance faz parte do significado

Os blocos 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 são reservados pela RFC 1918 para uso privado. Organizações diferentes podem reutilizar 10.0.0.7 porque esse endereço não possui significado global único e suas rotas não devem ser propagadas pela Internet pública. Ele continua sendo um endereço roteável dentro da organização, de uma rede privada virtual ou de uma nuvem privada. Privado descreve alcance, não uma garantia de segurança.

Outros blocos resolvem problemas diferentes. O prefixo 127.0.0.0/8 identifica loopback e mantém a comunicação dentro do próprio host. O bloco 169.254.0.0/16 fornece endereços IPv4 link-local quando a configuração normal não está disponível. Roteadores não devem encaminhá-los para outros links. Já 192.0.2.0/24, 198.51.100.0/24 e 203.0.113.0/24 são reservados para documentação, permitindo publicar exemplos sem apontar acidentalmente para uma organização real.

É por isso que os endereços de documentação usados neste artigo parecem plausíveis e, ainda assim, não apontam para os sistemas de uma empresa real. A reserva não torna o exemplo menos fiel, apenas retira um efeito colateral bastante indesejável. Há uma distinção importante nos exercícios: agregados amplos como 203.0.112.0/22 e 198.51.0.0/16 ultrapassam esses blocos reservados. Eles representam conjuntos matemáticos e tabelas hipotéticas, sem afirmar quem administra ou anuncia esse espaço na Internet real.

6.2 NAT e NAPT: reescrever exige lembrar

Se endereços privados não têm significado global, conservar 10.0.0.7 como origem não oferece ao servidor público um destino de retorno globalmente roteável. Muitas organizações podem usar esse mesmo endereço, e a Internet não possui uma rota pública que distinga cada ocorrência. Uma tradução de endereços de rede, ou NAT, de Network Address Translation, reescreve endereços entre dois domínios de numeração.

A forma comum em residências e nuvens faz mais que traduzir endereços. A tradução de endereços e portas, ou NAPT, de Network Address and Port Translation, permite que muitas conexões privadas compartilhem um único endereço público ao distinguir também portas TCP ou UDP. No uso cotidiano, essa variante costuma ser chamada apenas de NAT. Aqui nomearemos NAPT quando a porta participar da associação.

NAT não é NAPT (mas no dia a dia chamamos ambos de NAT)

NAT (Network Address Translation) reescreve apenas o endereço IP. É usado, por exemplo, para mapear um endereço privado em um público, mas mantém a porta original. Em cenários com muitos hosts, isso não escala porque cada endereço público só pode ter uma conexão por porta.

NAPT (Network Address and Port Translation) reescreve endereço e porta simultaneamente. É o mecanismo que permite que dezenas de máquinas compartilhem um único IPv4 público, pois a porta traduzida distingue cada fluxo. Quando falamos “NAT” no contexto residencial, quase sempre estamos falando de NAPT.

Vamos considerar a conexão que acompanharemos na seção seguinte, de 10.0.0.7:51514 para 198.51.100.20:443. Ao sair, ela pode tornar-se 203.0.113.9:40001 para o mesmo destino. O tradutor modifica a origem e ajusta os checksums afetados. Ao mesmo tempo, cria uma entrada de estado que relaciona a ponta pública à ponta privada e ao destino remoto.

A tabela mostra somente os campos visíveis no pacote. A informação decisiva permanece no tradutor: a associação criada entre as pontas antes e depois da reescrita.

Quando a resposta chega a 203.0.113.9:40001, a entrada permite restaurar 10.0.0.7:51514 como destino interno. Sem essa memória, o endereço público compartilhado não revelaria a qual conexão privada entregar o pacote. O NAPT dinâmico deste cenário é, portanto, uma função com estado e capacidade finita. Reescrever os campos é apenas uma parte do trabalho. A outra parte é conservar a associação que permitirá desfazer a tradução.

Esse estado explica também a assimetria de conexões iniciadas de fora. Um pacote que chega espontaneamente a uma porta pública sem uma associação existente não informa qual host privado deve recebê-lo. Publicar um serviço exige uma associação estática, um encaminhamento de porta ou outro mecanismo explícito. O fato de conexões externas falharem não prova que existe um firewall. Pode significar apenas que nenhuma tradução reversa foi definida.

A Figura 8 amplia apenas a memória do tradutor. Ela ainda não mostra DNS, a primeira entrega nem os roteadores da Internet. Na ida, o NAPT cria a relação entre as portas privada e pública. Na volta, essa relação identifica 10.0.0.7:51514. Uma chegada à porta pública 40002, sem estado correspondente, termina no tradutor porque o endereço público não contém a identidade de um host interno.

O endereço público não contém a identidade do host privado; a porta traduzida é a chave, e a chave só existe se o estado foi criado.

Figura 8: a resposta só reencontra 10.0.0.7:51514 porque o NAPT conservou a associação. Sem estado ou uma regra explícita, a chegada externa não determina um destino privado.

6.3 O que a tradução não promete

NAT conserva endereços públicos e pode participar de políticas de exposição, porém rompe a transparência fim a fim. Protocolos que transportam endereços no próprio payload, fluxos que mudam de caminho e conexões recebidas exigem tratamento adicional. NAT também não é sinônimo de firewall. Uma tradução pode coexistir com regras permissivas, e uma rede IPv6 sem NAT pode aplicar filtragem de estado rigorosa.

O detalhe da Figura 8 explicou por que a volta depende de estado. Ainda falta encaixar essa memória no percurso completo. O navegador começa com um nome, o host precisa alcançar o primeiro roteador, a Internet precisa encaminhar ao servidor e o transporte precisa reconhecer a conexão na volta. A próxima seção acompanhará como cada resultado alimenta a decisão seguinte.

A tradução alivia a escassez, mas não aumenta o espaço IPv4. Antes de mudar o tamanho do endereço, precisamos reunir as decisões que estudamos e acompanhar uma requisição completa. Somente esse percurso explica por que a resposta dirigida a um único endereço público consegue reencontrar uma entre muitas máquinas privadas.

7. De uma máquina privada a frankalcantara.com e de volta

Vamos considerar uma organização em que a estação da leitora usa 10.0.0.7/24, o roteador de saída usa 10.0.0.1 na rede interna e a organização compartilha um endereço IPv4 público, representado aqui por 203.0.113.9. Os endereços 10.0.0.7 e 10.0.0.1 pertencem ao espaço privado da RFC 1918. Já 203.0.113.9 pertence a um bloco reservado para documentação e desempenhará, somente no exemplo, o papel de endereço público. Essa combinação permite acompanhar a viagem sem afirmar qual endereço atende frankalcantara.com no instante da leitura.

Como a resposta volta para 10.0.0.7 se a Internet pública viu apenas 203.0.113.9?

A resposta curta será: a porta TCP traduzida identifica uma associação temporária mantida pelo NAPT. Essa frase, porém, esconde quase todo o mecanismo. Vamos abri-la desde o nome digitado no navegador até o byte entregue de volta ao processo correto.

Roteiro da viagem que vamos acompanhar

1. O navegador consulta o DNS e obtém um endereço IPv4 para frankalcantara.com.
2. A estação privada (10.0.0.7) consulta sua tabela de rotas e escolhe o gateway padrão (10.0.0.1).
3. ARP resolve o MAC do gateway, e o primeiro quadro é enviado.
4. O roteador de borda aplica NAPT: troca a origem privada por uma ponta pública (203.0.113.9:40001).
5. A Internet encaminha o pacote até o servidor (198.51.100.20), que responde para a ponta pública.
6. O NAPT, usando o estado que guardou, restaura o destino privado (10.0.0.7:51514).
7. O último quadro chega à estação, e o TCP entrega os dados à aplicação.

Cada passo depende do anterior. Pular um deles no diagnóstico é o erro mais comum.

7.1 O nome precisa tornar-se um endereço

Quando a leitora abre https://frankalcantara.com/, o navegador possui um nome, não um destino que um roteador consiga consultar em uma tabela IP. O resolver local obtém um ou mais endereços por meio do Sistema de Nomes de Domínio, ou DNS, de Domain Name System, a partir de um cache válido ou de consultas enviadas a servidores DNS. A RFC 1034 separa justamente esses papéis: a aplicação pede informação ao resolver, e o resolver localiza os registros necessários.

Onde está a hierarquia em um nome de domínio?

Um nome como api.example.com. é lido da direita para a esquerda quando percorremos sua hierarquia. O ponto final representa a raiz e costuma ser omitido na escrita cotidiana. com é um domínio de topo, ou TLD, de Top-Level Domain. example é o rótulo registrado sob com. api é um rótulo mais específico criado sob example.com para identificar um serviço ou outra parte do espaço de nomes.

Os pontos separam rótulos do nome. Eles não são barras de CIDR e não informam ao roteador qual interface deve ser usada. Também não garantem que cada fronteira textual corresponda a uma delegação administrativa diferente. A função do DNS é chegar a registros associados ao nome. A função do IP começa quando um endereço desses registros é escolhido como destino.

Em https://frankalcantara.com/, https identifica o esquema da URL, frankalcantara.com é o nome consultado e / é o caminho pedido ao servidor. Somente o nome participa da resolução DNS, e somente o endereço resultante aparece no cabeçalho IP.

Se o resultado não estiver em cache e o servidor DNS estiver fora da organização, as próprias consultas DNS atravessarão a rota padrão e poderão receber associações NAPT. Elas formam fluxos separados, com destinos e portas próprios. A conexão com o site só poderá começar depois que ao menos um endereço retornar. Para não misturar as duas viagens, continuaremos a partir desse resultado.

Suponha que o navegador escolha um endereço IPv4. Para manter o exemplo independente da hospedagem atual do site, vamos representar o endereço devolvido por 198.51.100.20, outro valor reservado para documentação. O nome continua importante para DNS, TLS e HTTP, mas os roteadores receberão pacotes cujo cabeçalho IP contém 198.51.100.20. Eles não encaminham a palavra frankalcantara.com.

7.2 O transporte cria as duas pontas da conversa

Neste percurso didático, vamos supor que o navegador use o Protocolo de Transferência de Hipertexto, ou HTTP, de Hypertext Transfer Protocol, protegido por TLS sobre uma conexão TCP. O cliente precisa então abrir uma conexão pelo Protocolo de Controle de Transmissão, ou TCP, de Transmission Control Protocol, e negociar a Segurança da Camada de Transporte, ou TLS, de Transport Layer Security, antes de enviar a requisição HTTP. Essa proteção de HTTP por TLS caracteriza o HTTPS.

O HTTP/3 usa QUIC sobre UDP e muda o transporte observado, mas preserva as decisões IP de endereço, rota e próximo salto. Quando atravessa NAPT, também exige uma associação para os endereços e as portas UDP. Neste exemplo, manteremos TCP para acompanhar uma única combinação de protocolo e pontas.

Portanto, não existe um único pacote da requisição que atravesse sozinho todo o caminho. Há uma sequência de pacotes, começando normalmente pela abertura TCP, seguida pela negociação criptográfica e pelos dados da aplicação. Para a camada IP, todos esses pacotes são datagramas independentes. Para acompanhar a associação, usaremos a primeira conexão TCP e conservaremos suas duas pontas.

Uma ponta TCP será identificada pela combinação entre um endereço IP e uma porta. Neste exemplo, o sistema operacional escolhe a porta local 51514, enquanto o servidor HTTPS espera na porta 443. A conexão será reconhecida pelo par formado pelas pontas 10.0.0.7:51514 e 198.51.100.20:443, como especifica a RFC 9293. O endereço IP aproxima o pacote da interface correta. A porta permite ao transporte encontrar a conexão e, por consequência, o processo correto naquela interface.

Porta física ou porta de transporte? Quando dissermos que um serviço escuta em uma porta, estaremos falando do identificador de $16$ bits usado por TCP ou UDP. O artigo anterior introduziu essa separação. A porta de transporte ajuda o sistema operacional a distinguir a conexão e o processo receptor dentro do dispositivo. Ela não é o conector físico de um switch, não pertence ao endereço IP e não aparece no cabeçalho IP.

7.3 A rota e o ARP realizam a primeira entrega

A rota conectada 10.0.0.0/24 não coincide com o destino 198.51.100.20. Como nenhuma rota mais específica está disponível neste cenário, a tabela escolhe a rota padrão pelo roteador 10.0.0.1. Se o MAC desse próximo salto ainda não estiver no cache, o ARP o resolve. A estação pode finalmente montar o primeiro quadro Ethernet.

Nesse primeiro link, três identificações coexistem:

O MAC de destino pertence ao roteador, mas o IPv4 de destino pertence ao servidor remoto. Essa diferença é a aplicação direta da Seção 4. O quadro precisa alcançar apenas o próximo equipamento. O pacote já precisa dizer qual destino final procuramos.

7.4 O NAPT cria uma ponta pública e conserva estado

Ao receber o quadro, o roteador remove o cabeçalho Ethernet e encontra um pacote IPv4 de 10.0.0.7 para 198.51.100.20. O payload começa com um segmento TCP da porta 51514 para a porta 443. Antes de enviá-lo ao provedor, o NAPT substitui o endereço IPv4 e a porta TCP da origem por uma ponta pública livre, por exemplo 203.0.113.9:40001. O tradutor também atualiza os checksums afetados e registra uma associação com estado:

Depois da tradução, o pacote que entra na Internet pública será 203.0.113.9:40001 → 198.51.100.20:443. O endereço privado desapareceu do cabeçalho visível no exterior, mas não desapareceu da memória do tradutor. É essa memória, e não um campo secreto no pacote, que permitirá a volta.

DNS escolheu um endereço, a rota escolheu o próximo salto, ARP encontrou um MAC e NAPT criou uma identidade pública temporária.

Confundir essas quatro decisões produz diagnósticos estranhos. O DNS não escolhe o gateway padrão. O ARP não procura frankalcantara.com. O NAPT não descobre a rota da Internet. Cada mecanismo entrega exatamente o objeto necessário à decisão seguinte.

7.5 A Internet encaminha o destino público e o servidor responde

O roteador da organização consulta sua tabela para 198.51.100.20, escolhe o próximo salto do provedor e cria um novo quadro para o link de saída. O provedor repete a operação. Cada roteador seguinte reduz o TTL, aplica a correspondência pelo prefixo mais longo ao endereço de destino e usa o encapsulamento apropriado ao próximo link. Nos links Ethernet, os endereços MAC pertencem a cada entrega local. Outros links podem usar outra forma de identificar seus participantes. O destino IPv4 permanece 198.51.100.20 durante a ida, enquanto a origem visível permanece 203.0.113.9 depois do NAPT.

Nenhum desses roteadores precisa conhecer 10.0.0.7, a porta 51514, a tabela interna da organização ou o caminho inteiro. Para encaminhar o pacote comum, basta aproximar o destino 198.51.100.20 segundo a própria FIB. Alguns equipamentos podem inspecionar campos adicionais por política, mas essa inspeção não faz parte do contrato mínimo de roteamento do IP.

O endereço escolhido pelo DNS pode terminar em uma CDN, uma rede de distribuição de conteúdo, em um balanceador de carga ou diretamente no servidor que processará a conexão. Essa arquitetura não altera a pergunta da camada IP. Alguma interface que anuncia alcançabilidade para o endereço recebe o pacote e o entrega ao transporte. Depois que TCP e TLS terminam suas negociações, os pacotes que carregam a requisição HTTP seguem a mesma associação enquanto ela permanecer válida.

O servidor responderá invertendo as pontas que conseguiu observar. Na Internet pública, a resposta TCP terá origem 198.51.100.20:443 e destino 203.0.113.9:40001. O servidor não precisa conhecer o endereço privado. Para ele, a conexão veio da ponta pública criada pelo NAPT.

O caminho de volta também não precisa repetir os roteadores da ida. Cada roteador consulta o destino público 203.0.113.9 em sua própria tabela e toma uma decisão local. O IP exige alcançabilidade, não simetria. No final desse caminho, o pacote chega ao equipamento que mantém a tradução da organização.

7.6 A tradução reversa restaura a ponta privada

O pacote de resposta chega ao tradutor como 198.51.100.20:443 → 203.0.113.9:40001. O NAPT consulta seu estado e encontra a entrada cuja ponta pública é 203.0.113.9:40001. A RFC 3022 descreve essa associação de endereço e porta, enquanto a RFC 5382 estabelece requisitos de comportamento para tradutores que atendem conexões TCP.

A entrada manda substituir o destino público pelo destino privado 10.0.0.7:51514. O pacote interno passa a ser 198.51.100.20:443 → 10.0.0.7:51514. Em seguida, o roteador encontra a rota conectada 10.0.0.0/24, resolve ou reutiliza o MAC de 10.0.0.7 e cria outro quadro Ethernet para o link interno.

A tabela resume as quatro formas assumidas pelas pontas sem esconder a direção:

A Figura 9 reúne as duas direções sem perder o estado que as conecta. Leia a faixa azul da esquerda para a direita e a faixa verde da direita para a esquerda. O painel central é a memória que transforma a porta pública 40001 no bilhete de volta para 10.0.0.7:51514.

Figura 9: o endereço público conduz a resposta até a fronteira da organização. A porta traduzida e o estado conservado pelo NAPT determinam qual estação privada e qual conexão devem recebê-la.

Quando o pacote alcança a estação, o IPv4 reconhece 10.0.0.7 como endereço local e entrega o payload ao TCP. O TCP usa a porta de destino 51514 e a outra ponta da conexão para localizar o estado correto. Somente então os dados remontados sobem para TLS e HTTP até chegarem ao navegador.

O IP, sozinho, não sabe que aquele pacote é uma resposta. Ele apenas encaminha um datagrama para um endereço. O NAPT reconhece a associação traduzida, o TCP reconhece a conexão e a aplicação interpreta os bytes como resposta HTTP. A volta funciona porque estados mantidos em camadas diferentes concordam sobre as mesmas pontas.

7.7 Como um endereço público atende muitas máquinas

Agora podemos responder rigorosamente à dúvida inicial. A organização possui um único endereço IPv4 público neste cenário, mas o NAPT pode reservar uma porta pública diferente para cada associação simultânea. Vamos acrescentar as estações B e C à conexão da estação A. A porta pública 40002, que estava sem associação na Figura 8, passará a ter estado quando B iniciar sua conexão. Duas estações podem até escolher a mesma porta privada sem produzir ambiguidade no exterior:

Uma resposta destinada a 203.0.113.9:40002 será entregue à estação B, enquanto uma resposta para a porta 40001 será entregue à estação A. No modelo didático, o par formado pelo endereço público e pela porta, junto com o protocolo, indexa a associação. Implementações reais também podem considerar a ponta remota e o estado da conexão ao decidir se aceitam o pacote e se reutilizam uma associação.

O endereço público compartilhado identifica a fronteira da organização, não uma estação interna específica. A porta traduzida separa associações nessa fronteira. Ela não aumenta o tamanho do endereço IPv4 e não cria capacidade infinita. Cada associação consome estado, uma porta disponível e memória até o encerramento ou o timeout correspondente.

Essa dependência explica três limites operacionais. Se a entrada expirar antes de uma resposta tardia, o tradutor já não saberá restaurar o destino privado. Se as portas ou a memória se esgotarem, novas conexões falharão mesmo que a rota continue correta. Se um pacote chegar de fora sem uma associação anterior nem uma regra estática, o endereço e a porta públicos não indicarão espontaneamente qual máquina privada deve recebê-lo.

Nada disso transforma NAT em sinônimo de firewall. A ausência de uma associação impede a tradução daquele fluxo, mas uma regra de encaminhamento de porta pode criar uma associação estática, e a política de segurança ainda precisa decidir o que aceitar. Também não é verdade que toda organização apareça na Internet com um único endereço. Ela pode usar um conjunto de endereços IPv4 públicos, sofrer outra tradução no provedor ou atribuir endereços IPv6 globais às interfaces.

7.8 Exercício da Seção 7

1. Dimensione o espaço de portas de uma tradução

Um tradutor reserva as portas públicas de $1024$ a $65\,535$ para associações TCP e usa uma porta por fluxo simultâneo para um mesmo endereço público e a mesma ponta remota, formada pelo IP do servidor e sua porta. Quantas associações cabem nesse modelo? Quantos endereços públicos são necessários para $150\,000$ fluxos simultâneos a essa mesma ponta remota, ignorando outras restrições?

Solução: Como os dois extremos pertencem ao intervalo, a quantidade inclusiva de portas por endereço público será

Um endereço comporta $64\,512$ associações. Dois endereços comportam

valor ainda menor que $150\,000$. Três endereços comportam

Logo, a quantidade mínima será dada por

O cálculo revela um limite que o diagrama de tradução não mostrava: portas públicas e entradas de estado são recursos consumíveis. Na prática, protocolo, destino remoto, tempos de retenção, portas reservadas e política de alocação reduzem ou repartem a capacidade utilizável. Dentro do modelo declarado, três endereços públicos são necessários.

A viagem está completa. O nome levou ao endereço remoto, os prefixos levaram cada pacote ao próximo salto, os quadros realizaram as entregas locais e a associação NAPT levou a resposta pública de volta à estação privada. A dependência dessa tradução nasce da escassez do IPv4. Para removê-la como requisito estrutural, precisamos ampliar o espaço de endereçamento e ajustar também o NDP.

8. IPv6: mais endereços e outro modo de vizinhança

O IPv6 amplia o endereço de $32$ para $128$ bits. Isso produz $2^{128}$ valores possíveis, mas o ganho arquitetural não se resume a conseguir mais números. O espaço maior permite delegar prefixos hierárquicos, conservar /64 em LANs comuns e recuperar o modelo em que interfaces podem possuir endereços globalmente únicos sem depender de NAPT para cada saída.

8.1 Ler e escrever 128 bits sem se perder

Escrever $128$ algarismos binários seria correto e impraticável. Por isso, um endereço IPv6 será representado em oito grupos hexadecimais de $16$ bits, separados por dois-pontos. Cada algarismo hexadecimal representa quatro bits. Quatro algarismos formam os $16$ bits de um grupo. Um endereço completo pode aparecer como 2001:0db8:1200:0000:0000:0000:0000:0010.

A forma textual pode ser comprimida por duas regras. Primeiro, zeros à esquerda de cada grupo são removidos: 0db8 torna-se db8 e 0010 torna-se 10. Depois, uma única sequência contínua de grupos iguais a zero pode ser substituída por ::. O resultado será 2001:db8:1200::10.

O :: pode aparecer no máximo uma vez, pois o endereço expandido precisa recuperar exatamente oito grupos. A forma recomendada pela RFC 5952 comprime a sequência mais longa de dois ou mais grupos zero, não comprime um único grupo e, se houver empate, escolhe a primeira sequência. Essas regras não alteram um único bit. Elas garantem que logs, configurações e comparações textuais tendam a convergir para uma representação previsível.

Os prefixos usam a mesma barra do CIDR. Em 2001:db8:1200::/48, os três primeiros grupos, cada um com $16$ bits, formam os $48$ bits fixos. A escrita hexadecimal torna a fronteira mais compacta, mas não altera a regra: bits contíguos à esquerda identificam o prefixo, e os bits restantes variam dentro do conjunto.

8.2 De um /48 organizacional a muitas LANs /64

O IPv6 transfere a aritmética da Seção 3 para um espaço de $128$ bits. Em 2001:db8:1200::/48, o número $48$ declara que os três primeiros grupos hexadecimais, 2001, db8 e 1200, estão fixos. Esse pode ser o bloco delegado à organização. Os $80$ bits restantes ainda não pertencem todos à mesma função.

Se a organização adotar /64 para cada LAN, avançará a fronteira em $64-48=16$ bits. Esses $16$ bits ocupam exatamente o quarto grupo hexadecimal e passam a identificar a sub-rede interna. Seus valores podem variar de 0000 a ffff:

Variar o quarto grupo produz $2^{16}=65\,536$ prefixos distintos. O primeiro é 2001:db8:1200:0000::/64, que normalmente escrevemos como 2001:db8:1200::/64. O último é 2001:db8:1200:ffff::/64. Cada um conserva os $64$ bits finais para identificadores de interface.

Observe a diferença entre quantidade de sub-redes e quantidade de endereços por sub-rede. Os $16$ bits intermediários produzem $65\,536$ escolhas de LAN. Depois de escolhida uma LAN, ainda restam $2^{64}$ combinações para a parte de interface. Não subtraímos dois endereços para rede e broadcast, porque o IPv6 não usa broadcast e não reserva o último endereço para esse papel.

A escala mudou de forma monumental. A operação lógica, porém, permaneceu a mesma: fixar bits contíguos à esquerda para definir conjuntos e avançar a fronteira para dividi-los.

8.3 Escopo e tipos de entrega

O prefixo 2001:db8::/32 é reservado para documentação. Endereços em fe80::/10 possuem escopo de link local e permitem que uma interface se comunique com vizinhos antes mesmo de obter um endereço global. ::1 representa loopback, enquanto :: é o endereço não especificado e não identifica uma interface alcançável.

IPv6 não possui broadcast. A entrega a uma interface usa unicast. A entrega a um grupo usa multicast. A entrega a uma entre várias interfaces que compartilham o mesmo endereço usa anycast, com a escolha determinada pelo roteamento. Retirar o broadcast evita tratar todas as interfaces do link como destinatárias lógicas de cada anúncio, embora os quadros multicast ainda precisem atravessar o meio conforme a tecnologia de link.

Em LANs IPv6 comuns, o /64 tem papel estrutural. A autoconfiguração de endereço sem estado, ou SLAAC, de Stateless Address Autoconfiguration, e outras expectativas da arquitetura foram construídas em torno de identificadores de interface de $64$ bits. Isso não significa que todo prefixo IPv6 usado em qualquer contexto seja /64. Significa que reduzir arbitrariamente o prefixo de uma LAN para imitar a economia de IPv4 pode quebrar mecanismos que pressupõem essa fronteira.

8.4 NDP constrói o entorno

No IPv4, apresentamos ARP como uma associação entre um endereço alcançável diretamente no link e um MAC. O NDP faz essa associação no IPv6, mas também constrói a visão local necessária ao host. Suas mensagens ICMPv6 cumprem papéis distintos:

• A solicitação de roteador, chamada Router Solicitation, pede que roteadores anunciem sua presença sem esperar o próximo anúncio periódico.
• O anúncio de roteador, chamado Router Advertisement, informa roteadores disponíveis, prefixos alcançáveis diretamente no link e parâmetros usados pela configuração.
• A solicitação de vizinho, chamada Neighbor Solicitation, procura o endereço de link de um vizinho, verifica alcançabilidade e participa da detecção de endereço duplicado.
• O anúncio de vizinho, chamado Neighbor Advertisement, responde à solicitação ou anuncia uma mudança de endereço de link.
• A mensagem de redirecionamento, chamada Redirect, permite que um roteador informe a um host que existe um próximo salto melhor no mesmo link ou que o próprio destino deve ser tratado como vizinho no mesmo link.

Depois dessa enumeração, a distinção importante é o fluxo. Ao ativar a interface, o host cria um endereço link-local e pode solicitar anúncios de roteadores. Com as informações recebidas, decide quais destinos estão alcançáveis diretamente no link, configura endereços conforme a política disponível e mantém uma lista de roteadores que podem funcionar como gateway padrão. Quando precisa enviar, consulta o cache do vizinho escolhido. Se ainda não houver uma associação utilizável, as mensagens de solicitação de vizinho e de anúncio de vizinho poderão resolvê-la ou validá-la. Um redirecionamento pode corrigir posteriormente a escolha do primeiro próximo salto sem funcionar como um protocolo geral de roteamento. A descoberta não está ao lado do encaminhamento, porque fornece parte dos dados que tornam o encaminhamento possível.

ARP × NDP: mais que um nome novo

No IPv4, o ARP tem uma única função: resolver um endereço IPv4 em um endereço MAC para o link atual. No IPv6, o NDP faz isso e mais: ele descobre roteadores, aprende prefixos, detecta endereços duplicados e mantém a alcançabilidade de vizinhos. Por isso, bloquear ICMPv6 não é o mesmo que bloquear ICMPv4 — você pode estar desligando a própria descoberta de vizinhança.

Em termos práticos: no IPv4, sem ARP você não entrega no link. No IPv6, sem NDP você não descobre o roteador, não aprende o prefixo e não resolve o vizinho. É um acoplamento maior.

A Figura 10 torna visível um percurso completo. Na fase azul, o host aprende um prefixo alcançável diretamente no link e um roteador padrão. Depois de a tabela de rotas escolher esse roteador como próximo salto para um destino remoto, o host consulta o cache. Neste exemplo, o anúncio de roteador não deixou uma associação de endereço de link utilizável, portanto ocorre o cache miss representado na fase verde. Em outro caso, a opção de endereço de origem da camada de enlace, chamada Source Link-Layer Address, no próprio anúncio poderia alimentar o cache e dispensar essa troca antes do primeiro pacote. O exemplo supõe Ethernet e, por isso, representa o endereço de link como um MAC.

Figura 10: NDP constrói o contexto de roteamento. Depois que a rota escolhe o próximo salto, o host consulta o cache e, se necessário, resolve o endereço de link usado na entrega local.

A mesma família ICMPv6 transporta mensagens Packet Too Big usadas pela descoberta da MTU do caminho. ICMPv6 não é um acessório de diagnóstico colocado ao lado do IPv6. Bloqueá-lo indiscriminadamente pode remover NDP, descoberta de roteadores e adaptação ao tamanho do caminho ao mesmo tempo.

8.5 Exercícios da Seção 8

1. Conte sub-redes IPv6 /64 dentro de um /48

Uma organização recebe 2001:db8:1200::/48 e usa /64 em cada LAN. Quantas LANs distintas pode numerar? Quais partes do endereço identificam a organização, a LAN e a interface?

Solução: Entre /48 e /64 há $64-48=16$ bits disponíveis para identificar sub-redes. Logo,

Os primeiros $48$ bits, escritos como 2001:db8:1200, permanecem comuns a toda a organização. O quarto grupo possui os $16$ bits que distinguem as LANs. Depois da fronteira /64, cada LAN mantém $64$ bits para identificadores de interface.

O primeiro prefixo pode ser escrito 2001:db8:1200::/64, e o último será 2001:db8:1200:ffff::/64. A quantidade de LANs vem somente dos dezesseis bits intermediários. Os $64$ bits finais não aumentam a quantidade de LANs, pois variam dentro de cada uma delas.

2. Separe descoberta de roteador e resolução de vizinho

Um host IPv6 já possui um endereço link-local e depende de anúncios para aprender sua rota de saída, sem configuração estática equivalente. No primeiro teste, ele ainda não recebeu nenhum anúncio de roteador. No segundo, recebeu o anúncio, obteve uma configuração de endereço global válida e instalou um roteador padrão, mas não possui uma associação de endereço de link utilizável para ele. A solicitação de vizinho enviada ao roteador não produz resposta. Qual decisão de encaminhamento está bloqueada em cada teste?

Solução: No primeiro teste, o host pode usar o endereço link-local para comunicações no próprio link, mas ainda não aprendeu pelo anúncio o roteador que usará como saída. Falta construir o contexto de roteamento para o destino remoto. Para comunicar-se com a Internet pública, também precisará de um endereço de origem com escopo adequado, pois o endereço link-local não pode atravessar roteadores.

No segundo teste, a decisão IP já existe. A tabela escolheu o roteador como próximo salto. O host, porém, ainda não obteve o endereço de link necessário para construir o quadro dirigido a esse vizinho. A falha está na resolução ou na alcançabilidade do vizinho, não na ausência da rota.

A comparação mostra por que NDP não é apenas um ARP renomeado. Uma parte de suas mensagens ajuda a formar o entorno de roteamento. Outra parte fornece a associação de vizinho consumida depois que a rota já escolheu o próximo salto.

Agora temos endereços, prefixos, vizinhos e rotas. Ainda falta entender como hosts e roteadores tornam descartes e limites do caminho observáveis. ICMP, TTL, Hop Limit e descoberta da MTU do caminho fornecerão evidências para distinguir uma rota existente de uma entrega que consegue atravessá-la.

9. ICMP, Hop Limit e descoberta do caminho

O contrato best effort permite que um roteador descarte um pacote que não consegue processar ou encaminhar. Sem um canal de controle, a origem observaria apenas ausência. O ICMP, de Internet Control Message Protocol (protocolo de mensagens de controle da Internet), torna algumas dessas condições observáveis ao transportar mensagens sobre o processamento de pacotes IP.

ICMP não é uma confirmação de entrega e não aparece para todo descarte. Uma mensagem ICMP também é transportada por IP, portanto pode perder-se, ser filtrada ou sofrer limitação de taxa. A evidência deve ser lida com cuidado: receber uma mensagem explica um evento, mas não receber nada não identifica sozinho a causa do silêncio.

A tabela transforma ICMP em evidência delimitada. O protocolo informa condições da camada de Internet, mas a aplicação ainda precisa relacioná-las ao fluxo, ao tamanho e ao instante corretos.

9.1 TTL, Hop Limit e traceroute

Um laço de roteamento poderia fazer o mesmo pacote circular indefinidamente. Para limitar essa vida, o IPv4 carrega o campo TTL e o IPv6 carrega o Hop Limit. Cada roteador reduz o valor antes de encaminhar. Se o resultado chega a zero, descarta o pacote e pode enviar ICMP Time Exceeded à origem. Apesar do nome histórico Time to Live, o comportamento operacional que observamos é uma contagem de saltos, não um cronômetro em segundos.

O traceroute transforma esse limite de segurança em instrumento de observação. Ele envia primeiro uma sonda com TTL ou Hop Limit igual a $1$. O primeiro roteador reduz o valor a zero, descarta o pacote e responde. A próxima sonda começa com $2$ e expira no segundo roteador. Ao aumentar o valor, a ferramenta provoca uma resposta em posições sucessivas do caminho.

O destino precisa encerrar a sequência com uma resposta reconhecível. Conforme a implementação, as sondas podem usar UDP, requisições ICMP de eco ou TCP. O destino poderá responder com Destination Unreachable, Echo Reply ou uma resposta TCP. Por isso, duas ferramentas chamadas traceroute podem atravessar filtros de maneiras diferentes e produzir saídas distintas.

A Figura 11 mostra três sondas sobre o mesmo caminho. Elas revelam os endereços das interfaces que enviaram respostas, não uma planta física completa. Também não obrigam todos os roteadores a responder, não provam que a volta segue a mesma rota e não medem o atraso isolado do link anterior. Cada tempo observado inclui a ida da sonda, o processamento da resposta e sua volta até a origem.

Figura 11: variar o TTL faz cada salto revelar-se pelo descarte. Silêncio em uma linha significa ausência de resposta observada, não ausência de roteador.

Um asterisco ou uma linha vazia em um salto significa somente que a resposta esperada não chegou dentro do prazo. O roteador pode ter encaminhado a sonda normalmente e limitado suas próprias respostas ICMP. Transformar silêncio em topologia é pedir à ferramenta uma certeza que o protocolo não prometeu.

9.2 A MTU do caminho

O caminho também pode rejeitar um pacote por tamanho. Cada link possui uma unidade máxima de transmissão, ou MTU, de Maximum Transmission Unit. Nesta discussão, a MTU limita o tamanho do pacote IP que o link transporta sem fragmentação. Ela não inclui o cabeçalho e o encerramento do quadro Ethernet.

Se um caminho atravessa $h$ links com limites $m_1,m_2,\ldots,m_h$, a PMTU, de Path Maximum Transmission Unit (unidade máxima de transmissão do caminho), será dada pelo menor deles:

Um link local com MTU $9000$ não autoriza a aplicação a supor que os demais links aceitam o mesmo tamanho. Basta um limite de $1400$ bytes adiante para tornar $1400$ a PMTU daquele caminho, naquela direção e naquele momento.

Em Ethernet com MTU $1500$, um pacote IPv4 com cabeçalho mínimo de $20$ bytes e UDP de $8$ bytes comporta no máximo

de payload UDP sem fragmentação. No IPv6, com cabeçalho base de $40$ bytes , o mesmo cálculo será

Os resultados, $1472$ e $1452$ bytes , medem o payload do UDP, não o tamanho do pacote IP nem o tamanho do quadro. Cabeçalhos IPv4 opcionais, cabeçalhos de extensão IPv6 e encapsulamentos adicionais consomem parte do mesmo orçamento.

No IPv4, um roteador pode fragmentar quando o pacote excede a MTU e a origem não marcou a proibição de fragmentar. No IPv6, roteadores não fragmentam: descartam o pacote grande demais e enviam ICMPv6 Packet Too Big. Somente a origem pode criar fragmentos. Nos dois casos, adaptar o tamanho na origem evita transferir a fragilidade da decisão para o meio do caminho.

Em sua forma clássica, a descoberta da MTU do caminho, ou PMTUD, de Path MTU Discovery, aprende o limite a partir dessas mensagens. No IPv4, a origem envia pacotes que não devem ser fragmentados e recebe ICMP Fragmentation Needed quando um roteador encontra um link menor. No IPv6, Packet Too Big informa a mesma necessidade estrutural, pois o roteador intermediário não possui a alternativa de fragmentar.

Se uma política bloqueia as mensagens necessárias, pacotes pequenos podem funcionar e pacotes grandes podem desaparecer. Esse modo de falha chama-se PMTU black hole: a rota existe e o primeiro contato pode funcionar, mas o tamanho escolhido não atravessa o caminho e a origem não recebe a evidência necessária para reduzi-lo. É uma explicação concreta para conexões que estabelecem e depois congelam quando começam a transferir mais dados.

PMTU black hole: o problema que parece instabilidade

Um PMTU black hole ocorre quando o caminho tem uma MTU menor que o tamanho que a origem está usando, mas as mensagens ICMP que informariam esse limite são bloqueadas. O sintoma clássico: conexões TCP estabelecem o handshake (pacotes pequenos), mas param ao enviar dados maiores (segmentos cheios). O diagnóstico correto não é “a rede está lenta”, mas “o tamanho do pacote está sendo rejeitado e não há aviso”.

A correção envolve permitir as mensagens ICMP necessárias, ajustar manualmente a MTU na origem, ou usar PLPMTUD, que sonda tamanhos e confirma a entrega sem depender exclusivamente de ICMP.

A Figura 12 separa os dois regimes sobre o caminho do exercício. O pacote de $1200$ bytes fica abaixo da PMTU de $1400$ bytes e chega ao destino. O pacote de $1450$ bytes encontra o mesmo caminho e a mesma rota, mas excede o menor link. Quando a mensagem ICMP que informa o limite é bloqueada, a origem não aprende um tamanho válido e repete o descarte.

Figura 12: bloquear a evidência do limite transforma um descarte corrigível em uma falha persistente e seletiva por tamanho.

A descoberta da MTU do caminho na camada de empacotamento, ou PLPMTUD, de Packetization Layer Path MTU Discovery, testa tamanhos com sondas e exige confirmação de entrega pelo transporte ou pela aplicação. Nesse nome, camada de empacotamento não acrescenta outra camada à pilha TCP/IP. Ela designa a função, situada no transporte ou na aplicação, que decide como os dados serão divididos em unidades entregues à camada de Internet. Uma sonda confirmada demonstra que aquele tamanho atravessou o caminho. Perdas repetidas provocam uma redução e uma nova confirmação. O mecanismo não depende exclusivamente de ICMP, mas também não transforma o bloqueio indiscriminado de ICMP em boa prática. Para UDP, que não confirma datagramas por conta própria, a aplicação precisa fornecer a confirmação necessária.

9.3 Exercícios da Seção 9

1. Rastreie quatro saltos com TTL crescente

Uma rota possui três roteadores antes do destino. Em qual equipamento expira cada sonda com TTL $1$, $2$, $3$ e $4$?

Solução: Cada roteador reduz o TTL antes de decidir pelo encaminhamento. A tabela registra o valor que chega a cada salto e a ação resultante.

As sondas $1$, $2$ e $3$ expiram, respectivamente, nos três roteadores. A sonda $4$ preserva valor $1$ depois do terceiro roteador e alcança o destino. O destino responde conforme o tipo de sonda, por exemplo com Echo Reply, Destination Unreachable para uma porta UDP fechada ou uma resposta TCP. O mecanismo revela quem respondeu quando cada limite terminou. Ausência de resposta continuaria sem provar ausência do salto.

2. Calcule payloads UDP sem fragmentação

Para MTU $1500$, calcule o payload UDP máximo com IPv4 sem opções e com IPv6 sem cabeçalhos de extensão.

Solução: A MTU limita o pacote IP inteiro. No IPv4, retiramos $20$ bytes do cabeçalho IP e $8$ do UDP:

No IPv6, retiramos $40$ bytes do cabeçalho base e $8$ do UDP:

A diferença é de $20$ bytes de payload por datagrama neste cenário, exatamente o acréscimo do cabeçalho base IPv6. Cabeçalhos IPv4 opcionais ou extensões IPv6 reduzem novamente o espaço disponível.

3. Encontre o gargalo de MTU em um caminho

Um caminho atravessa links com MTUs $9000$, $1500$, $1400$ e $1500$. Qual a PMTU? Qual a carga UDP IPv4 máxima com cabeçalho mínimo?

Solução: A PMTU é o menor limite entre os quatro links:

Retirando os cabeçalhos IPv4 e UDP,

O link de $1400$ bytes é o gargalo de tamanho. Configurar a origem segundo a MTU local de $9000$ não prova que o caminho aceita pacotes desse porte, tampouco que todos os links usam Ethernet. O limite relevante à aplicação será o maior tamanho de pacote IP que atravessa todos os links sem fragmentação, $1400$ bytes neste modelo.

4. Explique um PMTU black hole

Pacotes de $1200$ bytes chegam ao destino, mas pacotes de $1450$ bytes não chegam. A origem usa IPv4 com a indicação de não fragmentar. O caminho possui MTU $1400$ e mensagens ICMP Fragmentation Needed são bloqueadas. Desenvolva o mecanismo.

Solução: O pacote de $1200$ bytes satisfaz $1200\le1400$ e segue normalmente. O pacote de $1450$ bytes satisfaz $1450>1400$ e não cabe no link. Como a origem proibiu a fragmentação, o roteador o descarta e tenta enviar ICMP Fragmentation Needed informando o limite.

A política bloqueia essa resposta. A origem não aprende que precisa reduzir o pacote e continua retransmitindo no mesmo tamanho. A conectividade parece seletiva por tamanho: estabelecimento e mensagens pequenas funcionam, enquanto transferências maiores param. O diagnóstico precisa relacionar o corte entre $1200$ e $1450$ bytes à PMTU. A correção exige permitir as mensagens necessárias, reduzir corretamente o tamanho ou usar um mecanismo de sondagem como PLPMTUD.

5. Calcule o payload UDP com a PMTU mínima do IPv6

Um caminho IPv6 possui PMTU de $1280$ bytes . Calcule o maior payload UDP quando o pacote usa apenas o cabeçalho base IPv6. Depois, refaça a conta quando há $24$ bytes de cabeçalhos de extensão.

Solução: Com apenas o cabeçalho base, o orçamento contém $40$ bytes de IPv6 e $8$ bytes de UDP. O payload máximo será

Com $24$ bytes adicionais de cabeçalhos de extensão, esses bytes também pertencem ao pacote limitado pela PMTU:

Os cabeçalhos de extensão reduziram o payload de $1232$ para $1208$ bytes , diferença de $24$ bytes . A PMTU não mudou, mas mudou a parcela consumida antes dos dados da aplicação. Essa separação impede comparar o tamanho da mensagem com $1280$ sem contabilizar os cabeçalhos que viajarão no mesmo pacote.

Com isso, já conseguimos explicar tanto a escolha do caminho quanto um descarte provocado por seu limite de tamanho. Vamos voltar à operação central da LPM e torná-la executável em uma referência C++23.

10. Uma tabela de rotas em C++23

A matemática da Seção 5 já especificou o algoritmo. Para cada rota, construímos a máscara, testamos a coincidência com o destino e preservamos a candidata de maior comprimento. O programa a seguir transforma esse contrato em uma referência didática de CPU para tabelas IPv4 pequenas.

Ele não será um roteador de produção nem um benchmark. Sua função é tornar três invariantes executáveis: todo byte precisa estar entre $0$ e $255$, toda rede armazenada precisa estar normalizada com os bits variáveis zerados e a melhor rota precisa ser a coincidência mais específica examinada até aquele ponto do laço.

10.1 Representação e segurança das operações

Um endereço IPv4 cabe exatamente em std::uint32_t, inteiro sem sinal de $32$ bits. A função parse_ipv4 lê os quatro bytes da esquerda para a direita. A cada passo, desloca o valor acumulado por oito bits e insere o novo byte . Assim, 192.0.2.130 será escrito como o valor numérico

Essa representação preserva a ordem de significância usada pelas máscaras. Ela não depende de interpretar diretamente os bytes de memória da máquina, portanto não mistura a aritmética do exemplo com a ordem de bytes do hardware.

prefix_mask rejeita comprimentos maiores que $32$ e cria a máscara a partir de trinta e dois bits iguais a $1$. Para /24, desloca oito posições e produz 0xffff'ff00u. O caso /0 aparece antes do deslocamento porque deslocar um inteiro de $32$ bits por exatamente $32$ posições não é uma operação válida em C++. Os sufixos sem sinal também impedem que o bit mais alto transforme a operação em aritmética sinalizada.

make_route aplica a máscara ao endereço recebido. Desse modo, mesmo que a chamadora forneça 198.51.100.140/25, a tabela armazenará 198.51.100.128/25, a forma canônica do prefixo. Normalizar uma vez na criação evita repetir dúvidas sobre bits residuais em cada pacote. O comprimento entra como unsigned, é validado antes de qualquer conversão e só então cabe no campo std::uint8_t. Assim, um valor como $256$ não pode se transformar silenciosamente em zero antes da validação.

A estrutura Route conserva campos públicos para manter a representação visível. O contrato deste exemplo exige construir as entradas por make_route e não alterar depois a rede nem seu comprimento. Uma inicialização direta com campos inconsistentes contornaria essa normalização. Também supomos que o plano de controle já deixou uma entrada por prefixo, depois de resolver preferências e métricas. A consulta implementa somente LPM. Se duas entradas do mesmo prefixo forem fornecidas, ela conservará a primeira, sem comparar métricas nem distribuir tráfego por ECMP.

A interface de consulta recebe std::span<const Route>, uma visão não proprietária e contígua: a função lê a tabela fornecida por quem a chama sem copiá-la e sem assumir sua propriedade. O ponteiro retornado aponta para uma entrada desse armazenamento. Ele só pode ser usado enquanto o vetor existir e nenhum movimento, remoção ou realocação invalidar a entrada. Em main, o vetor permanece constante durante todas as consultas.

Salve o programa como rotas_ipv4.cpp. Para reproduzi-lo no Windows x64, abra o x64 Native Tools Command Prompt do Visual Studio e use um MSVC que ofereça /std:c++23preview. Esse é o modo específico de C++23 disponível nas versões verificadas, MSVC 19.44 e 19.51. A documentação de seleção do padrão distingue esse modo de /std:c++latest, que também pode habilitar recursos de rascunhos posteriores. O exemplo usa apenas a biblioteca padrão e executa na CPU.

#include <charconv>
#include <cstddef>
#include <cstdint>
#include <initializer_list>
#include <iostream>
#include <span>
#include <stdexcept>
#include <string>
#include <string_view>
#include <system_error>
#include <utility>
#include <vector>

[[nodiscard]] constexpr std::uint32_t prefix_mask(unsigned length) {
 if (length > 32u) {
 throw std::invalid_argument{"prefixo maior que 32"};
 }
 return length == 0 ? 0u : 0xffff'ffffu << (32u - length);
}

static_assert(prefix_mask(0) == 0u);
static_assert(prefix_mask(24) == 0xffff'ff00u);
static_assert(prefix_mask(32) == 0xffff'ffffu);

[[nodiscard]] std::uint32_t parse_ipv4(std::string_view text) {
 std::uint32_t value = 0;
 std::size_t begin = 0;

 for (int part = 0; part < 4; ++part) {
 const auto end = part == 3 ? text.size() : text.find('.', begin);
 if (end == std::string_view::npos || end == begin) {
 throw std::invalid_argument{"endereço IPv4 malformado"};
 }

 unsigned octet = 0;
 const auto first = text.data() + begin;
 const auto last = text.data() + end;
 const auto [ptr, error] = std::from_chars(first, last, octet);
 if (error != std::errc{} || ptr != last || octet > 255u) {
 throw std::invalid_argument{"byte IPv4 inválido"};
 }

 value = (value << 8u) | static_cast<std::uint32_t>(octet);
 begin = end + 1;
 }

 return value;
}

[[nodiscard]] std::string format_ipv4(std::uint32_t address) {
 return std::to_string((address >> 24u) & 0xffu) + "." +
 std::to_string((address >> 16u) & 0xffu) + "." +
 std::to_string((address >> 8u) & 0xffu) + "." +
 std::to_string(address & 0xffu);
}

struct Route {
 std::uint32_t network{};
 std::uint8_t length{};
 std::string next_hop;
};

[[nodiscard]] Route make_route(
 std::string_view address,
 unsigned length,
 std::string next_hop) {
 const auto mask = prefix_mask(length);
 return Route{parse_ipv4(address) & mask,
 static_cast<std::uint8_t>(length), std::move(next_hop)};
}

[[nodiscard]] const Route* longest_prefix_match(
 std::uint32_t destination,
 std::span<const Route> routes) {
 const Route* best = nullptr;

 for (const auto& route : routes) {
 const auto mask = prefix_mask(route.length);
 const bool matches = (destination & mask) == route.network;
 if (matches && (best == nullptr || route.length > best->length)) {
 best = &route;
 }
 }
 return best;
}

int main() {
 const std::vector<Route> routes{
 make_route("0.0.0.0", 0, "192.0.2.129"),
 make_route("198.51.0.0", 16, "192.0.2.140"),
 make_route("198.51.100.0", 24, "192.0.2.150"),
 make_route("198.51.100.128", 25, "192.0.2.160")};

 for (const std::string_view text : {
 "203.0.113.7", "198.51.7.9", "198.51.100.20", "198.51.100.140"}) {
 const auto destination = parse_ipv4(text);
 const auto* route = longest_prefix_match(destination, routes);
 if (route == nullptr) {
 std::cout << text << " sem rota\n";
 continue;
 }

 std::cout << text << " -> " << format_ipv4(route->network) << '/'
 << static_cast<unsigned>(route->length) << " via "
 << route->next_hop << '\n';
 }

 return 0;
}

Compile e execute no diretório em que salvou o arquivo:

cl /nologo /std:c++23preview /W4 /O2 /EHsc /utf-8 rotas_ipv4.cpp /Fe:rotas_ipv4.exe
rotas_ipv4.exe

A saída será:

203.0.113.7 -> 0.0.0.0/0 via 192.0.2.129
198.51.7.9 -> 198.51.0.0/16 via 192.0.2.140
198.51.100.20 -> 198.51.100.0/24 via 192.0.2.150
198.51.100.140 -> 198.51.100.128/25 via 192.0.2.160

10.2 Por que o laço precisa examinar a tabela inteira

O laço não encerra na primeira coincidência porque a tabela pode estar em qualquer ordem. Ao começar uma iteração, best será nulo ou apontará para a coincidência mais específica entre todas as entradas já examinadas. Se a rota atual não coincide, a invariante permanece. Se coincide e possui comprimento maior, best passa a apontar para ela. Quando o laço termina, nenhuma entrada ainda pode superar a escolhida.

Para $r$ rotas, essa busca linear executa $r$ testes no pior caso, portanto custa $O(r)$ tempo e $O(1)$ memória auxiliar. A complexidade é aceitável como referência de correção e como teste para tabelas pequenas. Roteadores com grandes FIBs usam árvores de prefixos, estruturas comprimidas ou hardware de busca associativa para sustentar muitas consultas por segundo. Mudar a estrutura não muda o contrato da LPM.

A saída percorre os quatro destinos do Exercício 1 da Seção 5.4. O primeiro destino encontra apenas /0. O segundo alcança /16. O terceiro entra em /24. O quarto ativa a exceção /25. Código, tabela e laboratório produzem os mesmos próximos saltos porque implementam a mesma comparação bit a bit.

O ramo sem rota permanece no programa mesmo com uma rota padrão na tabela. Se a entrada /0 for removida e nenhum prefixo coincidir, best continuará nulo. Esse caso lembra que a rota padrão é uma rota real e configurável, não um comportamento automático escondido no algoritmo.

11. Como auditar um caminho IP

11.1 Siga a ordem das decisões

Um diagnóstico de rede melhora quando segue a ordem das decisões que o pacote realmente enfrenta. Começar pelo traceroute em uma máquina com prefixo incorreto pula justamente a falha que impede o pacote de chegar ao primeiro roteador. Começar pela aplicação quando o próximo salto nem sequer possui uma associação de vizinho mistura sintomas da camada de enlace com sintomas da aplicação.

Vamos percorrer o caminho de dentro para fora.

1. Fixe a identidade da origem. Registre os endereços, os comprimentos de prefixo e as interfaces disponíveis. Calcule os prefixos conectados em vez de confiar apenas na configuração exibida. Cada um deles produzirá uma rota candidata, mas ainda não decide sozinho se o destino será tratado como alcançável diretamente no link diante de entradas mais específicas.

2. Separe nome de endereço. Se a aplicação começou por um nome, registre quais endereços o resolver devolveu e qual deles foi escolhido. Testar diretamente um endereço separa uma falha de DNS de uma falha no caminho IP. Essa separação não torna o DNS irrelevante. Ela impede atribuir ao roteamento um erro ocorrido antes de existir um destino IP.

3. Reproduza a escolha da rota. Liste todas as entradas que coincidem com o destino, incluindo rotas conectadas, estáticas, de host e a rota padrão. Aplique a correspondência pelo prefixo mais longo e, entre alternativas equivalentes para o mesmo prefixo, examine preferências e métricas. A entrada vencedora informa a interface e o próximo salto. Se for uma rota conectada, esse próximo salto poderá ser o próprio destino. Se apontar para um gateway, será o endereço desse roteador. Não pergunte apenas há uma rota? Pergunte qual entrada venceu e por quê.

4. Verifique a entrega ao vizinho correto. Se o destino for alcançável diretamente no link, a resolução ARP ou NDP deve procurar o próprio destino. Se for remoto, deve procurar o roteador escolhido. Um cache miss antes da tentativa é normal. Provoque tráfego e verifique se a resolução se completa, se recebe resposta e se a associação resultante aponta para o endereço de link esperado antes de levantar hipóteses sobre a Internet.

5. Localize a tradução, se ela existir. Em uma saída IPv4 privada, compare a ponta interna com a ponta observada no lado público e procure a associação correspondente. Para uma resposta, confirme que o estado ainda existe e aponta para a estação e a porta corretas. Não presuma NAPT apenas porque viu um endereço privado, e não presuma firewall apenas porque uma chegada externa falhou.

6. Observe os saltos sem transformar silêncio em certeza. Uma resposta de eco prova que uma resposta de eco retornou. Um traceroute revela interfaces que responderam e tempos de ida e volta das sondas. Não revela obrigatoriamente todos os roteadores, a rota física nem o caminho de volta. Compare mudanças entre medições equivalentes, mas conserve os limites da evidência.

7. Teste o tamanho quando o sintoma depender do volume. Se mensagens pequenas funcionam e mensagens maiores param, compare o tamanho do pacote IP com a PMTU. Procure Packet Too Big ou Fragmentation Needed e verifique se a aplicação ou o transporte confirma sondas de tamanho. O corte por tamanho é evidência mais específica que a afirmação genérica de que a rede está instável.

O procedimento não precisa terminar sempre no sétimo passo. O primeiro resultado incompatível com o esperado já delimita a investigação. A tabela seguinte relaciona sintomas frequentes ao mecanismo que merece o primeiro teste.

Checklist rápido para auditar um caminho IP

1. Origem: confira endereço, máscara e interface.
2. DNS: o nome resolve para o endereço esperado?
3. Rota: qual prefixo venceu pela LPM? Qual o próximo salto?
4. Vizinho: o ARP/NDP resolveu o próximo salto corretamente?
5. Tradução: há NAPT? A associação ainda está ativa?
6. Saltos: o traceroute mostra o caminho esperado? Silêncio não é ausência.
7. Tamanho: o pacote cabe na PMTU? ICMP está passando?

Não invente uma causa antes de verificar a etapa anterior. A maioria dos diagnósticos errados pula do passo 1 para o 6.

Cada linha evita uma conclusão comum demais. Um endereço privado não prova a existência de NAT. Um asterisco não prova a ausência de roteador. Uma rota padrão não prova que ela venceu. Um ping bem-sucedido não prova que a aplicação, a porta ou o tamanho real funcionará.

11.2 Observe configuração, rotas e vizinhos no Windows 11

No Windows 11, o PowerShell oferece uma visão estruturada da configuração e das decisões de nome, rota e vizinho. Os comandos abaixo são somente de leitura e podem ser executados sem alterar a configuração:

Get-NetIPConfiguration -All
Resolve-DnsName frankalcantara.com -Type A
Get-NetRoute -AddressFamily IPv4
Get-NetNeighbor -AddressFamily IPv4

Get-NetIPConfiguration -All reúne interfaces, endereços, gateways e servidores DNS, incluindo interfaces virtuais e desconectadas que a consulta padrão pode omitir. Resolve-DnsName mostra os registros IPv4 do tipo A devolvidos naquele instante. Trocar A por AAAA consulta endereços IPv6. O resultado pode mudar com o tempo e deve ser registrado junto com o teste. Get-NetRoute mostra os prefixos de destino, próximos saltos, interfaces e métricas da tabela IPv4. Get-NetNeighbor mostra o cache de vizinhos, isto é, as associações entre endereços IP e endereços de link. No IPv4 sobre Ethernet, esse cache inclui o estado aprendido pelo ARP.

O utilitário tradicional arp.exe também pode ser chamado dentro do PowerShell. Ele não é um cmdlet, mas continua útil para relacionar a explicação da Seção 4 à tabela observada no sistema:

arp -a

A saída é separada por interface e apresenta o IPv4 do vizinho, o endereço MAC associado e o tipo da entrada. Os rótulos podem aparecer como dynamic e static ou, conforme o idioma do sistema, como dinâmico e estático. Uma entrada dinâmica foi aprendida e pode expirar. Uma entrada estática não envelhece do mesmo modo, mas isso não prova que uma pessoa a configurou: o próprio Windows mantém entradas desse tipo para alguns endereços de multicast e broadcast, além das associações criadas pelo administrador.

Para provocar tráfego e observar uma associação específica, escolha um vizinho real do seu próprio link. Os endereços 192.0.2.0/24 usados neste artigo são reservados para documentação e, portanto, devem ser substituídos pelos valores do laboratório:

ping 192.0.2.150
arp -a 192.0.2.150

O ping não é necessário para consultar o cache. Ele aparece para provocar tráfego destinado ao vizinho escolhido. Se a associação ainda não estiver armazenada, o Windows precisará realizar a resolução ARP antes de enviar o pacote. Depois disso, a consulta deverá mostrar o MAC aprendido, desde que o host exista, esteja no mesmo link e responda à resolução.

Quando o computador possui várias interfaces, podemos restringir a consulta do arp.exe à tabela associada a um endereço IPv4 local:

arp -a -N 192.0.2.130
arp -a -v

No primeiro comando, 192.0.2.130 representa o endereço da interface local, não o endereço do vizinho procurado. A opção -N diferencia maiúsculas de minúsculas. O modo -v inclui entradas adicionais, como algumas entradas inválidas e relacionadas ao loopback.

arp -a não é uma ferramenta de varredura de rede. Ele mostra apenas associações presentes naquele momento, aprendidas durante comunicações anteriores ou instaladas pelo sistema e pelo administrador. A ausência de uma entrada não prova que o host não existe. Pode significar apenas que ainda não houve comunicação recente ou que a associação expirou.

Com Get-NetNeighbor -AddressFamily IPv6, o mesmo cmdlet consulta vizinhos IPv6. Nesse caso, as associações pertencem ao NDP, e não ao ARP. A sintaxe de arp.exe, Resolve-DnsName, Get-NetIPConfiguration, Get-NetRoute e Get-NetNeighbor está descrita na documentação oficial da Microsoft.

11.3 Laboratório controlado: modificar o cache ARP

Depois de observar a tabela, podemos estudar como uma intervenção muda seu estado. Os comandos seguintes permitem reconhecer duas operações de manutenção do cache, que devem ser realizadas somente em uma rede preparada para o experimento:

Use modificações apenas em um laboratório controlado. Remover ou criar associações pode exigir privilégios administrativos e interromper a entrega local. Depois da remoção, uma nova comunicação obriga o Windows a resolver novamente o endereço. Uma entrada estática incorreta faz o sistema dirigir quadros ao MAC errado. Confirme o endereço, a interface e o escopo antes de executar qualquer alteração.

arp -d 192.0.2.150 192.0.2.130
arp -s 192.0.2.150 00-AA-00-4F-2A-9C 192.0.2.130

O último argumento, 192.0.2.130, seleciona a interface local cuja tabela será modificada. Sem ele, o Windows escolhe a primeira interface aplicável. Substitua também esse valor e o MAC pelos dados do laboratório. São duas operações independentes: a primeira remove a entrada, enquanto a segunda instala a associação declarada.

Observe o estado antes e depois de cada operação com arp -a -N 192.0.2.130, substituindo o endereço pelo da interface do laboratório. Depois de remover uma entrada dinâmica, provoque uma nova comunicação e acompanhe sua reconstrução. Depois de instalar uma entrada estática, confirme que o MAC exibido corresponde ao valor informado. Se ela foi criada apenas para o experimento, remova essa associação específica ao terminar, permitindo que a resolução dinâmica volte a atender o vizinho.

12. Questões no estilo ENADE

Endereçamento, CIDR, escolha pelo prefixo mais específico, NAT, PMTU e ICMP exigem decisões encadeadas, não apenas memorização de siglas. Uma alternativa pode usar todos os termos corretos e ainda colocá-los na ordem errada. É esse tipo de erro plausível que as questões precisam separar.

Antes de escolher uma resposta, escreva a cadeia mínima do cenário: normalize os prefixos candidatos, aplique a LPM, resolva preferências entre rotas equivalentes e leia na vencedora a interface e o próximo salto. Somente então decida qual vizinho ARP ou NDP deverá resolver e examine tradução, ICMP ou tamanho. Se uma alternativa fala em ARP para um destino remoto, por exemplo, pergunte se o ARP procura o destino final ou o próximo salto do primeiro link. Se atribui a uma métrica a vitória sobre um prefixo mais específico, recupere a ordem da Seção 5.

O questionário a seguir reúne cinco questões no estilo ENADE para testar essas decisões em situações de roteamento e diagnóstico. As respostas permanecem ocultas até o final. Depois da última questão, o resultado separa acertos e erros e explica cada alternativa incorreta escolhida. O objetivo não será reconhecer vocabulário, mas reconstruir o percurso do pacote.

13. Conclusão

A pergunta que abriu o artigo era pequena: como um roteador escolhe a saída? Para respondê-la, precisamos descobrir que um endereço isolado não basta. O comprimento do prefixo transforma os bits iniciais em um conjunto, a máscara permite testar a pertença e o alinhamento torna possível dividir e agregar blocos sem anunciar endereços indevidos.

Essa aritmética chega diretamente ao primeiro link. O host usa seus prefixos para decidir se o próximo salto será o próprio destino ou o gateway padrão. ARP ou NDP resolve então o endereço de link desse vizinho. O quadro termina no próximo equipamento, mas o pacote IP segue com o destino original, salvo quando uma tradução explícita o modifica.

A viagem até frankalcantara.com reuniu essas decisões. O DNS transformou o nome em um endereço, a tabela de rotas escolheu o primeiro roteador e o NAPT trocou a ponta privada por uma ponta pública. Na volta, o endereço e a porta públicos localizaram a associação que restaurou 10.0.0.7:51514. Um único endereço IPv4 público atende muitas máquinas porque as portas e o estado separam as conexões, não porque o IP público contenha a identidade das máquinas internas.

Nos roteadores, várias rotas podem coincidir sem conflito. A correspondência pelo prefixo mais longo escolhe o menor conjunto que contém o destino, permitindo que um agregado amplo conviva com exceções específicas. Métricas e preferências resolvem alternativas para o mesmo prefixo, mas não apagam a hierarquia dos conjuntos. O programa C++23 tornou essa ordem visível em um laço e em uma invariante.

IPv4 e IPv6 preservam esse contrato de prefixos e próximos saltos, embora mudem o tamanho dos endereços e a descoberta local. O IPv6 amplia o espaço, usa NDP como parte estrutural do entorno e impede que roteadores intermediários fragmentem pacotes. ICMP torna alguns descartes observáveis. TTL e Hop Limit encerram laços e ainda oferecem ao traceroute seu mecanismo de investigação. A PMTU, por sua vez, lembra que uma rota existente pode continuar incapaz de transportar o tamanho escolhido pela aplicação.

O IP sabe para onde tentar enviar e qual vizinho deve receber a próxima tentativa. Ele ainda não sabe recuperar uma perda, controlar a taxa do remetente nem entregar bytes em ordem. Essas promessas começam no próximo artigo, quando TCP, UDP e QUIC escolherem contratos diferentes sobre o mesmo datagrama.

Uma rota correta entrega a tentativa. Confiabilidade ainda precisa ser construída nas pontas.

Apêndice A: Regras e Convenções para Atribuição de Endereços em Redes Locais

Além das características que a curiosa leitora já viu, as redes locais operam sob regras estritas de endereçamento que definem como as interfaces obtêm suas identidades. A atenta leitora notará que a arquitetura do IPv4 difere da abordagem adotada pelo IPv6, principalmente pela abundância de endereços e pela eliminação do NAPT na comunicação de ponta a ponta.

A.1 Atribuição de Endereços IPv4

No IPv4, a escassez de endereços globais moldou as práticas de atribuição em redes locais. O uso de endereços privados, definidos pela RFC 1918, é o padrão, e a configuração depende de mecanismos centrais ou estáticos.

• Configuração Dinâmica (DHCP): O Dynamic Host Configuration Protocol é o método mais frequente. Um servidor central fornece um endereço IP, a máscara de sub-rede, o gateway padrão e os servidores DNS. O controle é feito com estado (stateful), o que significa que o servidor registra qual endereço foi concedido a cada host e gerencia o tempo de concessão.
• Configuração Estática: Adotada para servidores e equipamentos de infraestrutura. A administração da rede define manualmente os parâmetros, garantindo previsibilidade para serviços que recebem conexões entrantes.
• Link-Local (APIPA): Se um host não encontrar um servidor DHCP e não possuir configuração estática, ele pode atribuir a si mesmo um endereço no bloco 169.254.0.0/16. Este endereço não é roteável e serve exclusivamente para estabelecer comunicação no mesmo segmento físico de rede.

Em redes IPv4 locais, o tamanho da sub-rede varia, mas o prefixo /24 é frequentemente adotado para redes residenciais e corporativas menores, oferecendo $254$ endereços disponíveis para distribuição.

A.2 Atribuição de Endereços IPv6 e a Fronteira do /64

A arquitetura do IPv6 foi desenhada para facilitar a autoconfiguração. Em uma rede IPv6, é esperado que uma interface possua múltiplos endereços simultaneamente, cada um destinado a um escopo específico.

• Link-Local (fe80::/10): Obrigatório. Todo dispositivo IPv6 gera automaticamente um endereço Link-Local assim que a interface é ativada. Ele serve exclusivamente para comunicação no mesmo link e é usado por protocolos de roteamento e descoberta de vizinhos (NDP).
• Unique Local Addresses - ULA (fc00::/7): Equivalentes aos endereços privados do IPv4. São usados para comunicação interna em redes que não necessitam de acesso direto à Internet.
• Global Unicast Addresses - GUA (2000::/3): Endereços globais. A convenção no IPv6 determina que os dispositivos da rede local recebam um endereço globalmente roteável.

Na atribuição de sub-redes para uma LAN, o tamanho do prefixo segue uma regra estabelecida para manter os mecanismos de vizinhança e autoconfiguração operacionais:

Por que o IPv6 insiste em /64 para uma LAN?

Não é uma escolha arbitrária. O IPv6 reserva os 64 bits finais para o identificador de interface porque o SLAAC e outros mecanismos (como o NDP) foram projetados para funcionar com essa fronteira. Usar um prefixo menor (ex.: /80) quebraria a autoconfiguração, pois os 64 bits de interface não estariam completos. É uma decisão arquitetural que sacrifica eficiência de espaço por simplicidade operacional.

Em outras palavras: no IPv4, a fronteira é flexível porque cada bit é precioso. No IPv6, a abundância permite fixar uma fronteira padrão que simplifica a vida de roteadores e hosts. Como o endereço IPv6 tem $128$ bits, a convenção técnica divide o endereço exatamente ao meio: os primeiros $64$ bits identificam a rede e os últimos $64$ bits identificam o dispositivo. Utilizar prefixos menores ou maiores na LAN, como /80, quebra o mecanismo de autoconfiguração padrão e inviabiliza funções do protocolo.

A.3 Métodos de Configuração no IPv6

O IPv6 fornece opções distintas para que um host configure sua interface e conheça o entorno da rede:

1. SLAAC (Stateless Address Autoconfiguration): O roteador envia mensagens de anúncio de roteador contendo o prefixo da rede. O dispositivo recebe essa informação e gera seus $64$ bits finais de forma independente.
2. SLAAC com DHCPv6 Stateless: O dispositivo utiliza o SLAAC para criar seu endereço IP e encontrar o gateway padrão, mas consulta um servidor DHCPv6 unicamente para obter parâmetros adicionais, como a lista de servidores DNS.
3. DHCPv6 Stateful: Funciona com a mesma lógica do DHCP do IPv4. Um servidor mantém um registro exato de qual endereço IPv6 foi atribuído a qual cliente.

A.4 Extensões de Privacidade

Quando o SLAAC foi projetado, o dispositivo utilizava seu próprio endereço MAC (através do método EUI-64) para gerar a segunda metade do endereço IPv6. Como o endereço de hardware não se altera, a prática permitia o rastreamento do host ao longo de diferentes redes e conexões.

Para mitigar a identificação cruzada, as Extensões de Privacidade (RFC 4941) alteraram o comportamento dos sistemas operacionais modernos. Os identificadores de interface passam a ser temporários e aleatórios. O dispositivo passa a operar com dois endereços globais ao mesmo tempo: um endereço estável para receber conexões entrantes na rede local e um endereço temporário que muda periodicamente para originar conexões, dificultando o rastreamento por servidores externos.

Acrônimos e Abreviações neste artigo

Referências

ARKKO, J.; COTTON, M.; VEGODA, L. RFC 5737: IPv4 Address Blocks Reserved for Documentation. IETF, 2010. Disponível em: https://www.rfc-editor.org/rfc/rfc5737. Acesso em: 21 ago. 2026.

BAKER, F. RFC 1812: Requirements for IP Version 4 Routers. IETF, 1995. Disponível em: https://www.rfc-editor.org/rfc/rfc1812. Acesso em: 21 ago. 2026.

BONICA, R.; BAKER, F.; HUSTON, G.; HINDEN, R.; TROAN, O.; GONT, F. RFC 8900: IP Fragmentation Considered Fragile. IETF, 2020. Disponível em: https://www.rfc-editor.org/rfc/rfc8900. Acesso em: 21 ago. 2026.

BRADEN, R. (ed.). RFC 1122: Requirements for Internet Hosts: Communication Layers. IETF, 1989. Disponível em: https://www.rfc-editor.org/rfc/rfc1122. Acesso em: 21 ago. 2026.

CHESHIRE, S.; ABOBA, B.; GUTTMAN, E. RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses. IETF, 2005. Disponível em: https://www.rfc-editor.org/rfc/rfc3927. Acesso em: 21 ago. 2026.

CONTA, A.; DEERING, S.; GUPTA, M. RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. IETF, 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4443. Acesso em: 21 ago. 2026.

DEERING, S.; HINDEN, R. RFC 8200: Internet Protocol, Version 6 (IPv6) Specification. IETF, 2017. Disponível em: https://www.rfc-editor.org/rfc/rfc8200. Acesso em: 21 ago. 2026.

EDDY, W. (ed.). RFC 9293: Transmission Control Protocol (TCP). IETF, 2022. Disponível em: https://www.rfc-editor.org/rfc/rfc9293. Acesso em: 4 set. 2026.

FAIRHURST, G.; JONES, T.; TÜXEN, M.; RÜNGELER, I.; VÖLKER, T. RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports. IETF, 2020. Disponível em: https://www.rfc-editor.org/rfc/rfc8899. Acesso em: 21 ago. 2026.

FULLER, V.; LI, T. RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. IETF, 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4632. Acesso em: 21 ago. 2026.

GONT, F.; ATKINSON, R.; PIGNATARO, C. RFC 7126: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options. IETF, 2014. Disponível em: https://www.rfc-editor.org/rfc/rfc7126. Acesso em: 29 ago. 2026.

GUHA, S.; BISWAS, K.; FORD, B.; SIVAKUMAR, S.; SRISURESH, P. RFC 5382: NAT Behavioral Requirements for TCP. IETF, 2008. Disponível em: https://www.rfc-editor.org/rfc/rfc5382. Acesso em: 4 set. 2026.

HINDEN, R.; DEERING, S. RFC 4291: IP Version 6 Addressing Architecture. IETF, 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4291. Acesso em: 21 ago. 2026.

HOPPS, C. RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm. IETF, 2000. Disponível em: https://www.rfc-editor.org/rfc/rfc2992. Acesso em: 28 ago. 2026.

IEEE. IEEE Std 802.1Q-2022: Bridges and Bridged Networks. IEEE Standards Association, 2022. Disponível em: https://standards.ieee.org/ieee/802.1Q/10323/. Acesso em: 4 set. 2026.

KAWAMURA, S.; KAWASHIMA, M. RFC 5952: A Recommendation for IPv6 Address Text Representation. IETF, 2010. Disponível em: https://www.rfc-editor.org/rfc/rfc5952. Acesso em: 21 ago. 2026.

LEINER, B. M.; CERF, V. G.; CLARK, D. D.; KAHN, R. E.; KLEINROCK, L.; LYNCH, D. C.; POSTEL, J.; ROBERTS, L. G.; WOLFF, S. A Brief History of the Internet. Internet Society, 1997. Disponível em: https://www.internetsociety.org/internet/history-internet/brief-history-internet/. Acesso em: 4 set. 2026.

MCCANN, J.; DEERING, S.; MOGUL, J.; HINDEN, R. RFC 8201: Path MTU Discovery for IP version 6. IETF, 2017. Disponível em: https://www.rfc-editor.org/rfc/rfc8201. Acesso em: 21 ago. 2026.

MICROSOFT. arp. Microsoft Learn, [s.d.]. Disponível em: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/arp. Acesso em: 4 set. 2026.

MICROSOFT. Get-NetIPConfiguration. Microsoft Learn, [s.d.]. Disponível em: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipconfiguration. Acesso em: 4 set. 2026.

MICROSOFT. Get-NetNeighbor. Microsoft Learn, [s.d.]. Disponível em: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netneighbor. Acesso em: 4 set. 2026.

MICROSOFT. Get-NetRoute. Microsoft Learn, [s.d.]. Disponível em: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute. Acesso em: 4 set. 2026.

MICROSOFT. Resolve-DnsName. Microsoft Learn, [s.d.]. Disponível em: https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname. Acesso em: 4 set. 2026.

MICROSOFT. /std (Specify Language Standard Version). Microsoft Learn, 2025. Disponível em: https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version. Acesso em: 4 set. 2026.

MOCKAPETRIS, P. RFC 1034: Domain Names: Concepts and Facilities. IETF, 1987. Disponível em: https://www.rfc-editor.org/rfc/rfc1034. Acesso em: 4 set. 2026.

MOGUL, J.; DEERING, S. RFC 1191: Path MTU Discovery. IETF, 1990. Disponível em: https://www.rfc-editor.org/rfc/rfc1191. Acesso em: 21 ago. 2026.

NARTEN, T.; NORDMARK, E.; SIMPSON, W.; SOLIMAN, H. RFC 4861: Neighbor Discovery for IP version 6 (IPv6). IETF, 2007. Disponível em: https://www.rfc-editor.org/rfc/rfc4861. Acesso em: 21 ago. 2026.

NICHOLS, K.; BLAKE, S.; BAKER, F.; BLACK, D. RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. IETF, 1998. Disponível em: https://www.rfc-editor.org/rfc/rfc2474. Acesso em: 29 ago. 2026.

NICKLESS, B. RFC 3849: IPv6 Address Prefix Reserved for Documentation. IETF, 2004. Disponível em: https://www.rfc-editor.org/rfc/rfc3849. Acesso em: 21 ago. 2026.

PLUMMER, D. C. RFC 826: An Ethernet Address Resolution Protocol. IETF, 1982. Disponível em: https://www.rfc-editor.org/rfc/rfc826. Acesso em: 21 ago. 2026.

POSTEL, J. RFC 791: Internet Protocol. IETF, 1981. Disponível em: https://www.rfc-editor.org/rfc/rfc791. Acesso em: 21 ago. 2026.

POSTEL, J. RFC 792: Internet Control Message Protocol. IETF, 1981. Disponível em: https://www.rfc-editor.org/rfc/rfc792. Acesso em: 21 ago. 2026.

RAMAKRISHNAN, K.; FLOYD, S.; BLACK, D. RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP. IETF, 2001. Disponível em: https://www.rfc-editor.org/rfc/rfc3168. Acesso em: 29 ago. 2026.

REKHTER, Y.; MOSKOWITZ, B.; KARRENBERG, D.; DE GROOT, G. J.; LEAR, E. RFC 1918: Address Allocation for Private Internets. IETF, 1996. Disponível em: https://www.rfc-editor.org/rfc/rfc1918. Acesso em: 21 ago. 2026.

RETANA, A.; WHITE, R.; FULLER, V.; MCPHERSON, D. RFC 3021: Using 31-Bit Prefixes on IPv4 Point-to-Point Links. IETF, 2000. Disponível em: https://www.rfc-editor.org/rfc/rfc3021. Acesso em: 21 ago. 2026.

SRISURESH, P.; EGEVANG, K. RFC 3022: Traditional IP Network Address Translator. IETF, 2001. Disponível em: https://www.rfc-editor.org/rfc/rfc3022. Acesso em: 4 set. 2026.

THOMSON, S.; NARTEN, T.; JINMEI, T. RFC 4862: IPv6 Stateless Address Autoconfiguration. IETF, 2007. Disponível em: https://www.rfc-editor.org/rfc/rfc4862. Acesso em: 21 ago. 2026.