Resumo

  • A RFC 894 atribuiu o EtherType hexadecimal 0800 ao IPv4 e mandou preencher com zeros o campo de dados que não alcançasse os 46 octetos mínimos da Ethernet. O preenchimento existia no enlace, mas não fazia parte do pacote IP nem de Total Length.
  • A recepção precisava conservar duas medidas: dimensionar o buffer pelo payload efetivamente entregue pela camada de enlace e encerrar a interpretação IP em Total Length. A RFC 6274 formalizou essa relação e exigiu descarte quando o enlace trouxesse menos bytes do que o IP declarava.
  • Octetos sem semântica IP continuavam capazes de carregar informação. A CERT/CC registrou drivers que reutilizavam conteúdo antigo como preenchimento; as erratas verificadas da RFC 894, por sua vez, preservam a diferença entre o texto imutável e a correção autorizada.

Dois máximos, um mesmo limite de propriedade

A RFC 894 aplicava-se à Ethernet de 10 Mb/s com endereços de 48 bits. A RFC 895, publicada no mesmo mês, tratava da Experimental Ethernet de 3 Mb/s com endereços de oito bits.

As duas redes não usavam o mesmo campo de tipo nem ofereciam o mesmo tamanho máximo ao IP. A primeira levava o valor hexadecimal 0800 e permitia datagramas de até 1.500 octetos. A segunda usava o tipo 513 em decimal, 1001 em octal, e chegava a 1.536.

Mesmo assim, as duas especificações diziam a mesma coisa sobre uma trama curta. Se a rede exigisse mais octetos para alcançar seu tamanho mínimo, o emissor acrescentaria preenchimento. Esse material não pertencia ao pacote IP e não entrava no campo Total Length.

O contraste separa a regra durável de seus parâmetros locais. Velocidade, endereço, valor de tipo e MTU podiam mudar. Uma camada de enlace não recebia, por causa disso, autoridade para ampliar o datagrama que transportava.

Quarenta e seis não substituíam vinte

Na RFC 894, o campo de dados Ethernet tinha no mínimo 46 octetos. Um cabeçalho IPv4 mínimo, sem opções, ocupa vinte. Se o datagrama não trouxesse payload, faltariam 26 octetos para o mínimo do enlace.

A solução não era escrever 46 no Total Length. Isso afirmaria que o IP possuía dados que nenhuma aplicação entregou. A solução era conservar Total Length em vinte e zerar a área externa necessária à Ethernet.

A base estava na RFC 791. Total Length mede o datagrama inteiro em octetos, incluindo cabeçalho IP e dados. IHL mede o cabeçalho em palavras de 32 bits e indica onde os dados começam. Portanto:

IHL × 4 <= Total Length <= tamanho do payload de enlace

O último sinal pode ser estrito em um pacote perfeitamente válido. O espaço restante não é “IP desconhecido”; é preenchimento reconhecido por outra camada.

0800 escolhia o protocolo, não contava o quadro

Na Ethernet, 0800 hexadecimal, ou 2048 decimal, identificava IPv4. Quando Ethernet e IEEE 802.3 podiam aparecer no mesmo cabo, a mesma posição de dois octetos precisava ser lida ora como Type, ora como Length.

A RFC 1122 registrou a distinção: valores até 1500 eram comprimentos de 802.3; EtherTypes válidos ficavam acima de 1500. Assim, 2048 selecionava a gramática IPv4. Não anunciava que o campo de dados tivesse 2048 octetos.

Depois de escolher a gramática, o receptor encontrava o fim no Total Length interno. O limite do buffer de enlace não podia substituir esse valor só porque havia bytes disponíveis depois dele.

A RFC 1122 também exigia que hosts em Ethernet de 10 Mb/s enviassem e recebessem a forma da RFC 894. Eles deveriam receber a forma IEEE 802 da RFC 1042 e poderiam enviá-la. Quem transmitisse ambas precisava oferecer uma configuração e adotar RFC 894 por padrão.

LLC e SNAP consumiam espaço do lado de fora

Na RFC 1042, o datagrama passava por IEEE 802.2 LLC e SNAP. Os dois cabeçalhos somavam oito octetos; os últimos dezesseis bits de SNAP mantinham o EtherType, 2048 para IP e 2054 para ARP.

Quando uma rede IEEE 802 tinha mínimo físico, o texto também mandava completar com zeros e também deixava esses zeros fora de Total Length. O mínimo de 28 octetos descrito para IP naquele contexto era a soma de vinte do cabeçalho IPv4 e oito de LLC/SNAP, sem o cabeçalho MAC. Não era uma nova definição dos 46 octetos da RFC 894.

A RFC 1122 indicou MTU 1500 para Ethernet e 1492 para 802.3. Os oito octetos externos explicavam a diferença. Eles reduziam a capacidade disponível sob uma encapsulação; não alteravam IHL, não criavam payload e não autorizavam o IP a ler padding.

A palavra errada continuou no original

Depois de estabelecer corretamente o mínimo de 46, a RFC 894 afirma que 1500 é o “minimum” do campo de dados e, na mesma frase, conclui que o datagrama IP tem máximo de 1500. Só uma das duas palavras pode estar correta.

A errata 570, técnica e verificada, troca minimum por maximum. Foi reportada em 2001. A errata 5141, reportada em 2017 e verificada em 2024, registra a mesma correção. A data recente é a data do registro, não a criação de um novo limite Ethernet.

A política de erratas do RFC Editor explica por que o erro ainda pode ser lido. RFCs publicados não são alterados. Erratas verificadas são consideradas corretas, mas não são incorporadas aos formatos TXT, PDF ou XML.

O original prova o que foi publicado. A errata prova como o trecho deve ser lido. Corrigir silenciosamente uma cópia local apaga a transformação; ignorar a correção preserva a origem e perde o sentido técnico. A evidência precisa das duas camadas.

Padding não era trailer

A RFC 893, também de abril de 1984, descreveu trailer encapsulation: cabeçalhos variáveis eram colocados depois dos dados para favorecer alinhamento e reduzir cópias em certos receptores. Era uma representação alternativa que dependia de suporte no vizinho.

O preenchimento da RFC 894 não movia o cabeçalho IP. Cabeçalho e dados permaneciam na ordem normal; zeros surgiam apenas depois do fim declarado. O receptor não reconstruía uma ordem, apenas parava de interpretar IP em Total Length.

Padding, trailer, opção IP e FCS podem parecer próximos do fim físico, mas pertencem a gramáticas distintas. A posição não lhes concede a mesma função.

O buffer externo não podia ser dimensionado pelo objeto interno

Em 2011, a RFC 6274 observou que a camada IP podia receber um payload de enlace maior que Total Length. Padding legítimo era uma causa comum; atividade maliciosa também era possível.

O buffer de recepção deveria ser alocado pelo tamanho informado pelo enlace. Caso contrário, o contêiner real poderia ser maior que a memória reservada a partir do objeto interno. Depois de recebido, porém, o parsing IP continuava limitado por Total Length.

O caso inverso precisava ser descartado e registrado. Se o enlace entregasse menos octetos do que Total Length, não havia padding que explicasse a ausência. IHL multiplicado por quatro também tinha de caber em Total Length.

Segurança não significa escolher uma medida vencedora. O enlace define quanto precisa ser armazenado; IP define quanto pode ser interpretado como datagrama.

O que IP não lia ainda podia revelar memória

Em janeiro de 2003, a CERT/CC VU#412115 documentou drivers que reutilizavam dados antigos do buffer para preencher quadros curtos, em vez de escrever zeros. Dependendo da implementação, o material podia vir da memória do kernel, de área estática do driver ou de um buffer de hardware.

Esses bytes não se tornavam payload IP válido. Um parser correto terminava antes. Ainda assim, o vizinho Ethernet podia observá-los. A fronteira semântica protegia a definição de IP, mas não apagava o que a placa transmitia.

Os registros de fornecedores da CERT distinguem produtos afetados, não afetados e desconhecidos. Não sustentam a afirmação de que todos os drivers vazavam. Sustentam uma conclusão mais precisa: a falta de inicialização do padding produziu um canal de divulgação real em implementações reportadas.

A camada que acrescenta um byte continua responsável pelo seu conteúdo, mesmo que a camada superior se recuse corretamente a interpretá-lo.

Fontes