Resumo

  • Para alterar apenas um campo do cabeçalho IP, o RFC 1141 ensinou a ajustar diretamente a soma de verificação já armazenada, economizando um novo cálculo do conjunto.
  • Em 1994, o RFC 1624 mostrou que o atalho confundia as duas representações do zero em complemento de um: produzia 0xFFFF quando o valor recalculado era 0x0000.

O roteador reduz o TTL de um pacote e carimba outra soma de verificação. Faz isso incontáveis vezes sem mudar os demais campos do cabeçalho. Recontar todas as parcelas a cada parada parece a tarefa perfeita para ser eliminada. A fórmula que prometia isso funcionava até topar com uma característica pouco simpática da aritmética usada: ela guardava dois zeros no mesmo armário.

O RFC 1071, de setembro de 1988, descreveu a soma de verificação da internet em palavras de 16 bits. Os valores são somados em complemento de um; o complemento do resultado vai para o campo do cabeçalho. Quem verifica pode somar o cabeçalho incluindo esse campo e exigir um resultado com todos os bits em um. A publicação procurava maneiras de tornar o trabalho mais rápido: somas em paralelo, diferentes ordens de bytes, retenção de transportes e cálculo junto com a cópia de memória. Também sugeria aproveitar o valor anterior quando só um campo mudasse.

O RFC 1141, de janeiro de 1990, desenvolveu o atalho para o valor de checksum realmente escrito no pacote. No exemplo de uma redução do TTL, somar 0x100 ao campo de controle refletia uma alteração de uma unidade no byte alto do par de 16 bits. Para uma rotina executada na passagem de cada pacote, a economia tinha boa lógica operacional. A fórmula parecia apenas reorganizar parcelas que já se conheciam.

Mas complemento de um não dá ao zero uma única roupa. Há o positivo, 0x0000, e o negativo, 0xFFFF. Ambos podem representar zero numa conta; o pacote, porém, leva a roupa específica que a máquina escolheu. O RFC 1624, de maio de 1994, explicou que a transformação de RFC 1141 aplicava uma propriedade distributiva que falhava no limite do zero. O resultado abreviado podia divergir em bits do resultado calculado desde o início.

O exemplo do documento é um teste pequeno e cruel. Um campo de 16 bits muda de 0x5555 para 0x3285. Os outros valores do cabeçalho somam 0xCD7A; o checksum antigo é 0xDD2F. Recalculando tudo, o novo campo deve guardar 0x0000. A fórmula do RFC 1141 escreve 0xFFFF. A equação corrigida, HC' = ~(~HC + ~m + m'), recupera 0x0000. O problema estava na representação armazenada do resultado. Com um campo não nulo no cabeçalho IP, a recomputação integral não produziria 0xFFFF naquele campo.

O destino ainda tinha uma palavra a dizer. Pelo RFC 1624, se a máquina receptora soma o cabeçalho inteiro, incluindo o checksum, e procura todos os bits em um, ela aceita as duas versões nesse exemplo. Se calcula novamente o valor do campo e o compara com os bits guardados, pode rejeitar o 0xFFFF do atalho. Uma única escolha de implementação na origem encontrava duas políticas de verificação no fim do caminho.

O próprio RFC contou como a condição apareceu. Testes de um produto que adotara o algoritmo do RFC 1141 revelaram a falha, e uma simulação verificou a correção. Sem nomear o produto ou contar instalações, o registro já fornecia o essencial: uma observação, valores repetíveis, a hipótese algébrica equivocada e uma nova fórmula. O texto ainda ofereceu uma versão por subtração com empréstimo para quem contava instruções.

O trabalho de atualizar sem recontar continuou válido. A lição estava no último passo: escrever exatamente os bits que o cálculo completo escreveria. Um zero pode parecer igual ao irmão no quadro-negro e chegar diferente à rotina de verificação do vizinho.