Header Checksum (IPv4)

O campo Header Checksum (Soma de Verificação do Cabeçalho), localizado nos últimos 16 bits do cabeçalho fixo do IPv4, é o mecanismo de integridade de dados utilizado exclusivamente para proteger a estrutura de controle do datagrama. Sua função primária é detectar erros de transmissão que possam ter corrompido o cabeçalho IP enquanto o pacote atravessava a rede, garantindo que informações críticas — como os endereços de origem e destino, o TTL e o campo Protocol — não sejam alteradas acidentalmente.

É fundamental entender que, ao contrário de protocolos da Camada de Enlace (como o Ethernet FCS — Frame Check Sequence, baseado em CRC-32) ou da Camada de Transporte (como o TCP/UDP Checksum, que cobre payload + pseudo-cabeçalho), o Header Checksum do IP cobre apenas o cabeçalho, e não a carga útil (payload) dos dados.

1. Escopo da Verificação: Apenas o Cabeçalho

A decisão de verificar apenas o cabeçalho é uma otimização de desempenho crítica para o funcionamento da Internet em escala.

• Proteção de Metadados: O foco é proteger os campos que controlam a entrega do pacote. Se um bit do endereço de origem ou destino for invertido, o pacote será entregue à pessoa errada (ou perdido). Se um bit do campo TTL ou Protocol for alterado, o roteador pode tomar decisões desastrosas (enviar para loop infinito ou entregar ao protocolo errado).
• Exclusão do Payload: A carga útil (dados da aplicação) não é coberta por este checksum. Se houver corrupção nos dados do usuário, o IPv4 simplesmente os entregará corrompidos.
  • Razão: Recalcular o checksum para pacotes grandes (ex: 1500 bytes) em cada salto da rota consumiria muito poder de processamento (CPU) nos roteadores centrais da internet, que processam bilhões de pacotes por segundo.
  • Delegação: A responsabilidade pela integridade do conteúdo é delegada à Camada de Transporte (ex: TCP ou UDP, que têm seus próprios checksums com pseudo-cabeçalho) ou à própria aplicação.

2. O Algoritmo: Soma em Complemento de Um

O checksum do IPv4 não usa um CRC (Cyclic Redundancy Check) complexo, mas um algoritmo matemático simples e rápido chamado Soma em Complemento de Um (One's Complement Sum), definido na RFC 1071.

Passo a Passo do Cálculo

1. Tratamento como Words: O cabeçalho é tratado como uma sequência de inteiros de 16 bits (words). Como o cabeçalho IPv4 tem tamanho múltiplo de 4 bytes (garantido pelo campo IHL), sempre é múltiplo de 2 bytes, dispensando padding.
2. Zeramento do Checksum: Antes de calcular, o campo de checksum (offset 10-11) no cabeçalho é temporariamente definido como zero.
3. Soma Acumulada: Todas as palavras de 16 bits do cabeçalho são somadas.
4. Carry End-Around (Transporte de Final): Se a soma gerar um bit excedente (um carry out no 17º bit, ou seja, se o resultado for maior que 65535), esse bit é adicionado de volta ao LSB do resultado (o bit mais significativo é somado ao menos significativo). Isso é chamado de "soma com wrap-around".
5. Complemento de Um: O resultado final da soma é invertido bit a bit (todos os 0s viram 1s e todos os 1s viram 0s). Esse valor invertido é colocado no campo Header Checksum.

Exemplo Numérico Simplificado

Considere um cabeçalho IPv4 de 20 bytes representado como 10 words de 16 bits (em hexa):

4500  0073  0000  4000  4011  0000  (checksum=0000)
C0A8  0001  C0A8  00C7

Somando todas as 10 words (com checksum zerado):

0x4500 + 0x0073 + 0x0000 + 0x4000 + 0x4011 + 0x0000 + 0xC0A8 + 0x0001 + 0xC0A8 + 0x00C7
= 0x246C2  (carry = 2, LSB = 0x46C2)
0x46C2 + 0x2 = 0x46C4  (após wrap-around)
Complemento de um: 0xB93B  →  este é o checksum enviado

Verificação no Destino

O receptor (ou roteador intermediário) realiza o mesmo processo: soma todas as palavras de 16 bits do cabeçalho incluindo o campo checksum recebido. Se o cabeçalho estiver íntegro, o resultado dessa soma será todos os bits ligados (0xFFFF em hexadecimal). Se qualquer bit tiver mudado, o resultado será diferente e o pacote será considerado inválido.

3. Necessidade de Recálculo em Cada Salto

Uma peculiaridade do IPv4 que torna o checksum indispensável (e dispendioso) é o fato de que ele deve ser recalculado em cada roteador pelo qual o pacote passa.

• O Motivo: O campo TTL (Time to Live) é decrementado em 1 a cada salto (hop). Como o TTL faz parte do cabeçalho, qualquer alteração no cabeçalho invalida o checksum original.
• O Impacto: Isso significa que, mesmo que o roteador não olhe para nenhum outro campo do cabeçalho, ele é obrigado a ler o cabeçalho, decrementar o TTL e recalcular o checksum antes de encaminhar o pacote para a próxima interface.
• Otimização Incremental: Para acelerar esse processo em roteadores de alta performance, ao invés de recalcular a soma de todo o cabeçalho novamente, o roteador utiliza um método incremental definido na RFC 1624:

HC_new = ~(~HC_old + ~TTL_old + TTL_new)

Isso evita a necessidade de ler os 20 bytes do cabeçalho novamente para o cálculo, processando apenas os campos alterados.

4. Tratamento de Erros

Se um roteador ou host receptor calcular o checksum e o resultado não for 0xFFFF:

• Descarte Imediato: O datagrama é silenciosamente descartado. Ele não é passado para a Camada de Transporte.
• Sem Notificação: Diferente da expiração do TTL, onde uma mensagem ICMP Type 11 é enviada, erros de checksum no cabeçalho não geram mensagens de erro. A lógica é que, se o cabeçalho está corrompido (por exemplo, o endereço de origem pode estar errado), tentar enviar uma mensagem de erro de volta pode ser inútil ou perigoso (poderia causar uma tempestade de pacotes de erro se o erro for físico e sistemático).
• Causas Comuns: Erros de checksum geralmente indicam problemas de hardware (fiação ruim, interferência eletromagnética), buffers de placa de rede com problemas, ou bugs de software no driver de rede do remetente que calculou o valor incorretamente.

Comparação com Outros Checksums

5. Por que o IPv6 Removeu o Header Checksum

Uma das otimizações do IPv6 foi eliminar o campo Header Checksum. A justificativa técnica da RFC 2460 foi:

1. Redundância: As camadas adjacentes (Enlace com FCS e Transporte com checksum + pseudo-cabeçalho) já protegem a integridade dos dados.
2. Custo de Processamento: Recalcular o checksum em cada salto era um custo significativo para roteadores de núcleo, sem benefício proporcional.
3. Raridade de Erros: Com fibras ópticas modernas e switches robustos, erros de bit no cabeçalho são excepcionalmente raros.
4. TTL no IPv6 (Hop Limit): Como o IPv6 também tem um campo Hop Limit equivalente ao TTL, a remoção do checksum poupou um recálculo em cada roteador.

6. Limitações Teóricas

Como o algoritmo é baseado em soma, ele possui algumas fraquezas teóricas conhecidas (embora raras na prática):

• Inserção de Zeros: A inserção de bytes com valor 0 não altera a soma.
• Troca de Ordem: Trocar a ordem de duas palavras de 16 bits no cabeçalho pode resultar na mesma soma (embora isso seja altamente improvável de ocorrer aleatoriamente na natureza).
• Inversão Complementar: Se dois bits em words de 16 bits forem invertidos (um complementa o erro do outro), o erro pode passar despercebido.
• Sensibilidade a Erros Multi-Bit: Erros que afetam mais de um bit no mesmo word podem compensar-se mutuamente, tornando o checksum incapaz de detectar a falha.

Apesar dessas limitações, o Header Checksum provou ser suficientemente robusto para detectar a maioria dos erros de transmissão física sem impor um custo computacional proibitivo aos roteadores.

7. Exemplo de Captura com tcpdump

# Capturar pacotes IPv4 e exibir checksum (campos detalhados)
tcpdump -n -i eth0 -v 'ip' | head -20

# Saída típica:
# IP (tos 0x0, ttl 64, id 12345, offset 0, flags [DF], proto TCP (6), length 60)
#   192.168.1.100.54321 > 192.168.1.1.80: Flags [S], cksum 0x1234 (correct)

O termo (correct) indica que o checksum foi validado pelo kernel no momento da captura. Se aparecer (incorrect), indica corrupção ou offloading (TX/RX Checksum Offloading em placas de rede modernas, que calculam o checksum em hardware).

8. Conclusão

O Header Checksum do IPv4 é um mecanismo legado, porém historicamente essencial, que garantiu a integridade dos cabeçalhos de bilhões de pacotes na Internet das décadas de 1980 a 2010. Sua remoção no IPv6 reflete a maturidade das tecnologias de enlace modernas (Ethernet, fibra óptica, switches com CRC-32 robusto) e a evolução do design de protocolos para priorizar performance em roteadores de núcleo. Para engenheiros de redes modernos, entender o checksum do IPv4 é importante sobretudo para diagnosticar problemas de offloading em placas de rede e entender por que o IPv6 conseguiu eliminar esse campo sem perda significativa de confiabilidade.