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

O artigo anterior terminou diante de um roteador. Sabemos que ele recebe um quadro por uma interface, extrai um pacote IP e escolhe uma saída. Ainda não sabemos como.

Essa lacuna é perigosa para quem escreve software. Um serviço pode estar ouvindo na porta correta e continuar inalcançável porque o prefixo foi calculado com um bit errado. Uma máquina pode resolver o nome e abrir uma conexão para o endereço errado porque uma rota mais específica venceu a rota esperada. Uma aplicação pode funcionar com mensagens pequenas e congelar com mensagens grandes porque o caminho não consegue transportar o pacote e a mensagem ICMP necessária foi bloqueada.

Vamos abrir a camada IP até que cada um desses sintomas produza uma conta. Começaremos pelo contrato de melhor esforço, transformaremos endereços em prefixos, seguiremos um pacote pelo gateway, compararemos IPv4 e IPv6 e terminaremos com dois laboratórios. O Artigo 4 poderá então acrescentar confiabilidade e congestionamento sobre uma camada cujo comportamento já conhecemos.

1. O contrato mínimo que conecta redes diferentes

O Protocolo de Internet, ou IP, de Internet Protocol, transporta datagramas entre interfaces identificadas por endereços de tamanho fixo. No IPv4, o endereço possui $32$ bits. No IPv6, possui $128$ bits. Um roteador recebe cada datagrama como uma unidade independente, examina o destino e tenta aproximá-lo da rede correspondente.

O verbo tenta carrega o contrato inteiro. IP não confirma entrega, não recupera perda, não preserva ordem, não elimina duplicatas e não controla a taxa do remetente. O IPv4 protege apenas seu cabeçalho com uma soma de verificação; o IPv6 remove até essa soma do cabeçalho base. Quando um roteador detecta certos problemas, pode enviar uma mensagem ICMP. Pode não significa que a origem sempre receberá a mensagem.

Essa pobreza é uma escolha arquitetural. A camada IP precisa atravessar Ethernet, Wi-Fi, fibra de operadora, túneis e tecnologias que ainda não existiam quando o IPv4 foi publicado. Prometer apenas endereçamento e encaminhamento permite que os enlaces mudem sem obrigar toda aplicação a mudar junto.

Há três objetos que precisamos separar desde já. Um nome indica o recurso procurado, como api.example.com. Um endereço indica uma interface alcançável no espaço IP, como 192.0.2.130. Uma rota indica o próximo passo para um conjunto de endereços, como 192.0.2.128/26 via interface Ethernet. DNS mapeia nomes para endereços; a tabela de rotas mapeia prefixos para próximos saltos.

Nome, endereço e rota respondem a perguntas diferentes.

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

Um cabeçalho IPv4 sem opções ocupa $20$ bytes. Ele inclui a versão, o comprimento do próprio cabeçalho, o comprimento total, campos de fragmentação, o tempo de vida, o identificador do protocolo transportado, a soma de verificação e os endereços de origem e destino. Opções podem aumentar o cabeçalho até $60$ bytes, embora o caminho comum evite esse regime.

O cabeçalho base do IPv6 ocupa sempre $40$ bytes. Ele mantém versão, classe de tráfego, rótulo de fluxo, comprimento da carga, próximo cabeçalho, limite de saltos e dois endereços de $128$ bits. Funções opcionais saem do cabeçalho base e aparecem em cabeçalhos de extensão encadeados. A origem, não um roteador intermediário, é responsável por fragmentar no IPv6.

A Figura 1 preserva a escala em palavras de $32$ bits. O IPv6 dobra o tamanho mínimo do cabeçalho, de $20$ para $40$ bytes, porém usa a maior parte do espaço adicional nos endereços. Ao mesmo tempo, remove do caminho comum a soma de verificação do cabeçalho, os campos de fragmentação e o comprimento variável.

Figura 1: o IPv6 troca um cabeçalho base variável e modificado por roteadores por um cabeçalho fixo, com endereços maiores e extensões encadeadas.

O campo TTL, de Time to Live (tempo de vida), do IPv4 e o limite de saltos do IPv6 cumprem hoje a mesma função operacional. Cada roteador reduz o valor em pelo menos uma unidade. Se ele chega a zero, o pacote é descartado. O nome TTL preserva a origem histórica em tempo; a operação observável na Internet atual é uma contagem de saltos.

O campo protocolo do IPv4 e o campo próximo cabeçalho do IPv6 dizem quem interpreta a carga seguinte. O valor pode indicar TCP, UDP, ICMP ou, no IPv6, outro cabeçalho de extensão. Portas não pertencem ao IP. Elas aparecem no transporte e só existem se o protocolo carregado definir esse conceito.

3. CIDR: uma fronteira escrita com bits

Um endereço IPv4 como 192.0.2.130 é uma forma decimal de escrever $32$ bits. Sozinho, ele não diz quais bits identificam o prefixo da rede e quais distinguem interfaces dentro desse prefixo. A notação CIDR, de Classless Inter-Domain Routing (roteamento entre domínios sem classes), acrescenta o comprimento do prefixo. Em 192.0.2.130/26, os primeiros $26$ bits pertencem ao prefixo e os $6$ restantes variam dentro do bloco.

A máscara equivalente possui $26$ uns seguidos de $6$ zeros:

Para obter o endereço da rede, fazemos um E lógico entre o endereço e a máscara. O último octeto de $130$ será $10000010_2$; o da máscara será $11000000_2$. Logo,

O prefixo será 192.0.2.128/26. Há $32-26=6$ bits de hospedeiro e, portanto, $2^6=64$ endereços no bloco, de 192.0.2.128 a 192.0.2.191. No uso IPv4 tradicional, o primeiro identifica a rede e o último é a difusão dirigida do prefixo; restam $64-2=62$ endereços para interfaces.

A Figura 2 torna a fronteira visível. Os dois primeiros bits do último octeto permanecem fixos; os seis seguintes podem variar. A rede não será determinada pela aparência decimal de 130, mas pela operação bit a bit.

Figura 2: a barra /26 fixa os primeiros 26 bits; todos os endereços que compartilham esses bits pertencem ao mesmo bloco de 64 endereços.

A fórmula $2^{32-p}-2$, na qual $p$ é o comprimento do prefixo, serve para contar endereços utilizáveis no modelo convencional de sub-redes IPv4 até /30. Não a trate como lei universal. Uma rota /32 identifica um único endereço; um enlace ponto a ponto /31 pode usar os dois endereços segundo a RFC 3021; e o IPv6 não possui difusão, portanto não reserva o último endereço do prefixo para esse papel.

3.1 Exercícios da Seção 3

1. Calcule rede, difusão e faixa de um /26

Para 192.0.2.130/26, determine máscara, rede, difusão, primeiro endereço de hospedeiro, último endereço de hospedeiro e quantidade convencional de hospedeiros.

Solução: O prefixo /26 deixa $6$ bits variáveis. O tamanho do bloco será

No último octeto, os blocos começam em $0$, $64$, $128$ e $192$. Como $130$ pertence ao intervalo de $128$ a $191$, obtemos:

O endereço 192.0.2.130 é o segundo endereço utilizável desse bloco. A conta não depende de classes A, B ou C; depende dos $26$ bits fixos.

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$, emprestando $3$ bits. A quantidade de sub-redes será

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

Os oito blocos são contíguos, não se sobrepõem e recompõem exatamente os $256$ endereços do /24.

3. Escolha o menor prefixo para cinquenta interfaces

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

Solução: Precisamos encontrar $h$, a quantidade de bits de hospedeiro, tal que

Com $h=5$, temos $2^5-2=30$, insuficiente. Com $h=6$, temos $2^6-2=62$, suficiente. O comprimento do prefixo será

O menor bloco é um /26, com $64$ endereços totais e $62$ convencionais. Um /25 serviria, mas desperdiçaria mais endereços; um /27 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 octeto. O valor $112$ é divisível por quatro, e o bloco cobre de $112$ a $115$.

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

endereços, exatamente os $4\times256=1024$ endereços dos quatro /24. Se a sequência começasse em 203.0.113.0/24, não estaria alinhada em uma fronteira /22 e o mesmo resumo incluiria endereços externos ao conjunto.

5. 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?

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

Cada LAN mantém $64$ bits para identificadores de interface. A escala muda a decisão: no IPv6, não precisamos economizar interfaces encurtando a parte de hospedeiro em LANs comuns; usamos os dezesseis bits intermediários para um plano hierárquico de sub-redes.

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 difusão permanece correta.

4. Entrega local, ARP e o gateway padrão

Antes de consultar um roteador, o hospedeiro compara o destino com seus prefixos diretamente conectados. Se origem e destino pertencem ao mesmo prefixo, a entrega será local. A origem precisa descobrir qual endereço MAC corresponde ao IPv4 de destino e usa o ARP, de Address Resolution Protocol (protocolo de resolução de endereços), para fazer essa associação.

Se o destino não pertence a um prefixo local, a origem não procura o MAC do destino remoto. Ela procura o MAC do próximo salto, normalmente o gateway padrão, e coloca o pacote IP dentro de um quadro destinado a esse roteador. O roteador remove o quadro, reduz o TTL, consulta sua tabela e cria outro quadro para o enlace seguinte.

A Figura 3 mostra a invariante que costuma faltar. O endereço IP de destino continua 198.51.100.20 nos dois enlaces. Os endereços MAC mudam de A para R1 e, depois, de R1 para B. O quadro pertence a um enlace; o pacote atravessa vários.

Figura 3: a decisão de sub-rede escolhe de quem precisamos conhecer o endereço de enlace; o destino IP remoto não vira o destino MAC do primeiro quadro.

ARP usa difusão para perguntar quem possui um IPv4 e unicast para devolver a associação, embora variações sejam possíveis. A associação entra em um cache temporário. Se a entrada estiver errada ou antiga, o pacote pode ser enviado à interface errada mesmo com uma rota correta. Novamente, tabelas diferentes produzem sintomas parecidos.

No IPv6, a descoberta de vizinhos, ou NDP, de Neighbor Discovery Protocol (protocolo de descoberta de vizinhos), usa mensagens ICMPv6 e multicast em vez de ARP e difusão. NDP também descobre roteadores, prefixos e parâmetros do enlace. Bloquear ICMPv6 como se fosse telemetria opcional pode impedir o próprio IPv6 de funcionar.

5. A correspondência pelo prefixo mais longo

Uma tabela de rotas contém prefixos, próximos saltos, interfaces e, conforme o sistema, métricas e origens administrativas. Para um destino, o roteador encontra todas as entradas cujo prefixo coincide e escolhe a de maior comprimento. Essa regra chama-se correspondência pelo prefixo mais longo, ou LPM, de Longest Prefix Match.

Considere a tabela:

O destino 198.51.100.140 coincide com as quatro entradas. A /25 vence porque fixa $25$ bits, mais que /24, /16 e /0. A Figura 4 alinha os prefixos sobre o mesmo endereço para mostrar que a escolha é uma relação de conjunto: cada entrada mais específica recorta o conjunto anterior.

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

O comprimento do prefixo resolve a primeira disputa. Se duas rotas possuem o mesmo prefixo, o sistema aplica outros critérios, como distância administrativa, preferência do protocolo e métrica. Esses critérios variam entre implementações e protocolos. O Artigo 6 tratará da política entre sistemas autônomos; aqui conservaremos a regra que todo encaminhador IP precisa aplicar ao destino.

5.1 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: Avaliamos as coincidências e escolhemos o maior prefixo.

A rota padrão não será usada somente quando nenhuma rota existe. Ela coincide com tudo e perde para qualquer entrada mais específica.

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 198.51.100.128/25 cobre de .128 a .255. Logo, .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 podem tomar rotas diferentes porque a fronteira do prefixo passa exatamente entre eles.

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 octetos de $112$ a $115$, portanto inclui o destino. Roteadores externos encaminharão o pacote ao anunciante, pois a rota agregada afirma alcançabilidade.

Se o roteador interno não possui caminho para o /24 ausente e conserva apenas uma rota padrão que aponta de volta, pode formar um laço. 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 retornarem ao caminho externo.

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, a métrica menor, $10$, vence segundo a hipótese do enunciado.

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; não anulam a regra de maior prefixo.

A tabela separa as duas ordens de decisão: primeiro o conjunto de destinos descrito pelo prefixo; somente entre rotas igualmente específicas entra a métrica declarada no enunciado.

5. 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 não há outro roteador como próximo salto. 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; o cache ARP fornece o destino de camada 2 nesse enlace. Uma tabela correta não substitui a outra.

No laboratório de rotas, escolha os quatro destinos do exercício 1 e observe o conjunto de candidatos. Depois desative a exceção /25: o destino continua alcançável, mas muda de próximo salto porque a /24 passa a ser a melhor coincidência.

6. Endereços especiais e tradução no IPv4

Nem todo endereço de $32$ bits possui o mesmo alcance. Os blocos 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 são privados segundo a RFC 1918. Podem ser reutilizados por organizações diferentes porque não devem ser roteados na Internet pública. 127.0.0.0/8 representa retorno local; 169.254.0.0/16 serve a configuração de enlace local; blocos como 192.0.2.0/24, 198.51.100.0/24 e 203.0.113.0/24 são reservados para documentação.

É por isso que todos os exemplos deste artigo parecem familiares e, ainda assim, não apontam para uma organização real.

Uma tradução de endereços de rede, ou NAT, de Network Address Translation, reescreve endereços entre domínios. A forma comum em residências e nuvens também traduz portas. Uma conexão de 10.0.0.7:51000 para 198.51.100.20:443 pode sair como 203.0.113.9:40001 para o mesmo destino. O tradutor guarda uma associação para devolver a resposta pública à origem privada correta.

Tabela 3: a tradução de origem conserva estado para que a resposta dirigida ao endereço e à porta públicos retorne à conexão privada.

NAT conserva endereços públicos e permite políticas de exposição, porém rompe a transparência fim a fim. Protocolos que transportam endereços no corpo, conexões iniciadas de fora e fluxos que mudam de caminho exigem conhecimento 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.

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

Um endereço IPv6 possui $128$ bits e será escrito em oito grupos hexadecimais de $16$ bits, como 2001:0db8:1200:0000:0000:0000:0000:0010. Zeros à esquerda de cada grupo podem ser removidos. Uma única sequência contínua de grupos iguais a zero pode ser comprimida com ::. O resultado será 2001:db8:1200::10.

A compressão não altera o endereço. Ela apenas escolhe uma representação textual. Como :: pode aparecer no máximo uma vez, a quantidade de grupos omitidos continua dedutível. Em caso de empate entre sequências de zeros, a forma canônica da RFC 5952 comprime a primeira sequência mais longa.

O prefixo 2001:db8::/32 é reservado para documentação. Endereços fe80::/10 possuem escopo de enlace local e são essenciais à descoberta de vizinhos. O endereço ::1 representa retorno local. IPv6 não possui difusão; usa unicast, multicast e anycast. Substituir difusão por grupos multicast reduz o conjunto de interfaces que precisam processar certas mensagens, embora o enlace ainda transporte os quadros correspondentes.

Em LANs IPv6 comuns, o prefixo /64 tem papel estrutural. Mecanismos como a autoconfiguração sem estado, ou SLAAC, de Stateless Address Autoconfiguration, foram projetados em torno de identificadores de interface de $64$ bits. Isso não significa que todo prefixo IPv6 do mundo seja /64; significa que reduzir arbitrariamente uma LAN para imitar a economia de endereços do IPv4 pode quebrar expectativas do protocolo.

NDP usa ICMPv6 para solicitação e anúncio de vizinho, descoberta de roteadores, prefixos e redirecionamentos. A mesma família de mensagens também sustenta a descoberta da MTU do caminho. ICMPv6 não é um acessório de diagnóstico colocado ao lado do IPv6. É parte do mecanismo pelo qual o IPv6 encontra e mantém seu entorno.

8. ICMP, limite de saltos e descoberta do caminho

O ICMP, de Internet Control Message Protocol (protocolo de mensagens de controle da Internet), relata condições sobre o processamento de pacotes. Mensagens de destino inalcançável, tempo excedido, pacote grande demais e eco permitem que hospedeiros e roteadores expliquem certos descartes. Elas não tornam o IP confiável: uma mensagem ICMP também pode se perder ou ser filtrada.

O traceroute transforma o limite de saltos em instrumento. Ele envia uma sonda com TTL igual a $1$. O primeiro roteador reduz o valor a zero, descarta o pacote e responde com ICMP de tempo excedido. A sonda seguinte usa TTL igual a $2$ e expira no segundo roteador. Repetindo o procedimento, a ferramenta revela interfaces ao longo do caminho até receber uma resposta do destino.

A Figura 5 mostra três sondas sobre o mesmo caminho. Elas não obrigam os roteadores a responder, não provam que a volta segue a mesma rota e não medem apenas o enlace até cada salto. Cada tempo observado inclui ida da sonda, processamento e volta da resposta.

Figura 5: 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.

8.1 A MTU do caminho

Cada enlace possui uma unidade máxima de transmissão, ou MTU, de Maximum Transmission Unit. A MTU do caminho será o menor limite entre origem e destino. 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 carga UDP sem fragmentação. No IPv6, com cabeçalho base de $40$ bytes, o mesmo cálculo produz $1500-40-8=1452$ bytes antes de considerar cabeçalhos de extensão.

Na descoberta da MTU do caminho, a origem envia pacotes que não devem ser fragmentados e reduz o tamanho quando recebe ICMP informando o limite. Se uma política bloqueia essas mensagens, pacotes pequenos podem funcionar e pacotes grandes podem desaparecer. É o buraco negro de PMTU: a conectividade existe, mas o tamanho escolhido não atravessa o caminho e a origem não recebe a evidência necessária para corrigir-se.

A descoberta da MTU pela camada de empacotamento, ou PLPMTUD, de Packetization Layer Path MTU Discovery, infere tamanhos utilizáveis com sondas e confirmações do próprio transporte. Ela reduz a dependência de mensagens ICMP, mas não transforma o bloqueio indiscriminado de ICMP em boa prática.

8.2 Exercícios da Seção 8

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 encaminhar.

O destino responde conforme a sonda usada, por exemplo com eco, porta inalcançável ou uma resposta TCP. O mecanismo revela o salto onde cada limite termina.

2. Calcule cargas UDP sem fragmentação

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

Solução: 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 por datagrama neste cenário. Cabeçalhos IPv4 opcionais ou extensões IPv6 reduzem novamente a carga disponível.

3. Encontre o gargalo de MTU em um caminho

Um caminho atravessa enlaces 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 valor:

Retirando os cabeçalhos IPv4 e UDP,

Configurar a origem segundo a MTU local de $9000$ não prova que o caminho aceita quadros gigantes. O limite relevante à aplicação é o menor enlace ainda não contornado por encapsulamento ou fragmentação.

4. Explique um buraco negro de PMTU

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 de fragmentação necessária são bloqueadas. Desenvolva o mecanismo.

Solução: O pacote de $1200$ bytes cabe no enlace de MTU $1400$ e segue normalmente. O pacote de $1450$ bytes não cabe. Como não pode ser fragmentado, o roteador o descarta e tenta enviar ICMP 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 conserto exige permitir as mensagens necessárias ou usar um mecanismo de sondagem como PLPMTUD.

5. 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 e usa uma porta por fluxo simultâneo para um mesmo endereço público e destino. Quantas associações cabem nesse modelo? Quantos endereços públicos são necessários para $150\,000$ fluxos simultâneos, ignorando outras restrições?

Solução: A quantidade inclusiva de portas será

Dois endereços comportariam $2\times64\,512=129\,024$ fluxos, ainda insuficientes. Três comportariam $193\,536$. Logo,

O modelo mostra por que a tradução também possui capacidade de estado. Na prática, protocolos, destinos, tempos de retenção e políticas de alocação alteram o limite utilizável.

9. Uma tabela de rotas em C++23

O programa a seguir implementa a operação central deste artigo para IPv4: interpretar endereços e prefixos, normalizar a rede e escolher a rota de maior comprimento. Ele é uma referência de correção para tabelas pequenas, não um encaminhador de produção. Um roteador real usa estruturas e hardware capazes de consultar muitas entradas por pacote.

Os endereços são armazenados em std::uint32_t. Toda operação de deslocamento usa valores sem sinal e trata /0 separadamente, evitando deslocar por $32$ bits, que seria inválido. O código compila como C++23 no MSVC com /std:c++latest /W4 /O2 /EHsc.

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

[[nodiscard]] constexpr std::uint32_t prefix_mask(std::uint8_t length) {
    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{"octeto 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,
    std::uint8_t length,
    std::string next_hop) {
    if (length > 32) {
        throw std::invalid_argument{"prefixo maior que 32"};
    }
    const auto mask = prefix_mask(length);
    return Route{parse_ipv4(address) & mask, 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';
    }
}

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

O laço não encerra na primeira coincidência porque a tabela pode estar em qualquer ordem. Ele preserva a invariante de que best aponta para a coincidência mais específica vista até aquele instante. Ao final, a saída reproduz a Tabela do exercício 1 e o laboratório interativo.

10. Como auditar um caminho IP

Comece registrando o endereço, o prefixo e a tabela de rotas da própria origem. Não pergunte apenas há uma rota?; pergunte qual prefixo venceu e por qual interface. Em seguida, determine se o próximo salto é o destino ou um roteador. Para IPv4, confira a associação ARP; para IPv6, confira a entrada de vizinho e o roteador descoberto.

Depois, meça o caminho sem transformar silêncio em certeza. Uma resposta de eco prova que uma resposta de eco retornou. Ausência de resposta pode significar filtro, perda, limitação de taxa ou destino inalcançável. Um traceroute revela interfaces que responderam e tempos de ida e volta das sondas, não a topologia física completa nem a rota de retorno.

Quando apenas mensagens grandes falham, compare o tamanho no fio com a PMTU e procure mensagens ICMP de pacote grande demais ou fragmentação necessária. Quando apenas conexões iniciadas de fora falham, localize traduções e filtros de estado. Quando um destino específico segue o caminho errado, liste todas as rotas coincidentes antes de olhar métricas. A entrada mais específica costuma explicar o desvio.

11. Conclusão

A camada IP reduz uma rede de redes a uma operação repetida: interpretar um destino, escolher o prefixo mais específico e enviar o datagrama ao próximo salto. Endereços não são nomes, prefixos não são classes históricas e rotas não são trajetos completos. Cada tabela responde apenas pela próxima decisão.

No enlace local, ARP ou NDP transforma o próximo salto IP em um destino de camada 2. Entre enlaces, o quadro muda e o pacote preserva o destino, salvo traduções explícitas. IPv6 amplia endereços e reorganiza o cabeçalho, mas mantém o contrato de datagramas independentes e melhor esforço. ICMP torna parte dos descartes observável; TTL e limite de saltos impedem que um laço dure para sempre e ainda permitem que o traceroute investigue o caminho.

O IP sabe para onde tentar enviar. Não sabe como recuperar uma perda, controlar um remetente ou 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.

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.

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.

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.

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.

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.

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.

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.

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: 21 ago. 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.