Resumo

  • O primeiro bit do tipo de opção IPv4 dizia se a opção ficava apenas no fragmento de offset zero ou acompanhava todos os fragmentos.
  • A fragmentação criava cabeçalhos derivados: conjunto de opções, IHL, comprimento total, offset, MF e checksum podiam variar legitimamente.
  • Copy 1 não garantia bytes iguais na chegada, processamento, autenticidade ou entrega. Opções mutáveis podiam registrar caminhos diferentes, e o fragmento zero preservava a autoridade de remontagem.

A mesma instrução não produziu o mesmo diário

A palavra “cópia” sugere um objeto imóvel. Faz-se uma réplica e, se ambas sobrevivem, seus conteúdos deveriam continuar iguais. A opção IPv4 que registrava rota desafiava essa intuição. A réplica recebia a mesma condição inicial, mas cada roteador posterior podia acrescentar informação permitida pelo formato.

RFC 815 observa que fragmentos do mesmo datagrama podem percorrer caminhos distintos. Quando uma opção source-and-record-route foi copiada em todos eles, as versões recebidas podem registrar rotas diferentes. A divergência não demonstra, sozinha, corrupção; pode ser a consequência do trabalho que a opção autorizava.

Na remontagem descrita, usa-se a rota de retorno registrada no primeiro fragmento e ignoram-se as versões alternativas. A regra não tenta fundir todos os históricos. Ela preserva uma origem de autoridade: o fragmento cujo offset é zero.

Esse caso expõe a função exata do bit Copy. Ele distribui uma opção para que cada fragmento, agora encaminhável separadamente, tenha a instrução necessária. Não certifica que os estados posteriores permanecerão iguais.

Um bit dentro do tipo decidia a herança

RFC 791 divide o octeto de tipo de opção em um bit Copied, dois bits Class e cinco bits Number. Copied zero significa que a opção é copiada somente para o primeiro fragmento. Copied um significa que aparece em todos.

O “primeiro” é estrutural. É o fragmento com Fragment Offset igual a zero, mesmo que ele chegue depois dos demais. Esse fragmento conserva o conjunto completo das opções originais. Fragmentos não zero mantêm apenas as opções cujo bit manda copiar.

Loose Source and Record Route tem tipo 131 e Copy 1. Record Route tem tipo 7 e Copy 0. Se o datagrama original carrega os dois, o fragmento zero herda ambos; os posteriores ficam apenas com o tipo 131. Strict Source and Record Route, tipo 137, e Stream Identifier, tipo 136, também têm Copy 1. Timestamp, tipo 68, tem Copy 0.

O mecanismo evita duas simplificações ruins. Copiar todas as opções faria cada fragmento carregar estado que não precisava ser replicado. Deixar todas apenas no primeiro poderia retirar uma instrução necessária aos fragmentos encaminhados de forma independente.

Fragmentar exigia reconstruir, não fotocopiar

RFC 760, de janeiro de 1980, já separava opções copiadas para cada fragmento daquelas mantidas só no primeiro. Sua descrição mandava copiar seletivamente o cabeçalho Internet ao criar o fragmento seguinte. RFC 791 tornou a decisão explícita no tipo.

Quando uma opção Copy 0 sai de um fragmento posterior, o tamanho do cabeçalho muda. O Internet Header Length precisa representar essa nova realidade. Total Length passa a refletir a carga daquela peça. Fragment Offset aponta a posição original, More Fragments informa se ainda há continuação, e Header Checksum deve ser recalculado depois das mudanças.

Portanto, dois fragmentos do mesmo datagrama podem ter IHL diferente sem violação. A identidade de remontagem não depende de cabeçalhos completos idênticos. Eles são derivados que compartilham origem, não clones.

Um checksum válido também tem alcance estreito. Ele mostra que os bytes do cabeçalho recebido são coerentes com o algoritmo. Não mostra que o fragmentador preservou toda opção Copy 1 nem que omitiu corretamente as de Copy 0. A regra semântica precisa ser verificada separadamente.

Copy não era um selo de importância ou segurança

Record Route e Timestamp não se tornam descartáveis porque usam zero. Eles permanecem no fragmento zero, que carrega a seleção integral do datagrama original. O bit responde onde copiar, não quanto valor atribuir.

Da mesma forma, uma opção Copy 1 não adquire prioridade, confiabilidade, criptografia, autenticação ou prova de entrega. A antiga Basic Security Option tinha tipo 130 e Copy 1, mas sua política de rótulo não nascia desse bit. Confundir posição com segurança transformaria uma regra de montagem em alegação que ela nunca fez.

O registro de parâmetros IPv4 da IANA mantém Copy, Class, Number, Value, Name e Reference para os tipos atribuídos. Isso permite confirmar o código e sua fonte normativa. Não informa presença no tráfego atual, suporte em produtos ou sucesso de processamento.

Registro, implementação, emissão, passagem pelo caminho e efeito observado são camadas diferentes. A tabela oficial fecha a primeira; não substitui as outras.

O tamanho definitivo esperava o offset zero

RFC 815 explica que o receptor pode não conhecer o tamanho final do cabeçalho enquanto o primeiro fragmento não chegou. Um fragmento posterior pode ter removido todas as opções Copy 0 e, por isso, mostrar um IHL menor.

Se esse fragmento chega primeiro no relógio, ele ainda não é o primeiro na semântica. Tratar seu cabeçalho curto como original completo transforma uma visão parcial legítima em conclusão falsa.

RFC 6274 aplica o limite a verificações de segurança. Para saber se o pacote remontado comporta o cabeçalho de transporte alegado, é preciso usar o IHL do fragmento zero. Sem ele, uma implementação pode executar um teste preliminar, mas deve reaplicar a condição completa quando a peça autorizada aparecer.

Provisório é um estado operacional útil. Permite avançar sem fingir certeza. O risco nasce quando um sistema de alto desempenho descarta a possibilidade de revisão e grava o primeiro cálculo como decisão final.

EOL e NOP faziam parte da reconstrução

End of Option List e No Operation encerram ou alinham a área de opções. Ao retirar opções não copiadas de um cabeçalho posterior, o fragmentador pode precisar reconstruir esse fim e o preenchimento para manter o alinhamento de 32 bits.

Não basta apagar octetos com o primeiro bit em zero. O processamento precisa respeitar comprimento e limites de cada opção, não cortar uma estrutura no meio, ajustar IHL e fechar o cabeçalho antes de calcular seu checksum.

Uma opção desconhecida continua tendo gramática. O implementador pode não compreender seu uso completo, mas não recebe por isso autoridade para inventar um tratamento. A estrutura comum possibilita avançar, copiar segundo o tipo ou rejeitar explicitamente.

Esse é o sentido de uma especificação comum enxuta: poucas decisões ficam globais, porém aquelas poucas são determinísticas e auditáveis.

A fragilidade da fragmentação veio depois como pressão, não como apagamento

RFC 8900 reafirma que todas as opções IPv4 aparecem no primeiro fragmento e apenas as de Copy 1 aparecem nos seguintes. O documento reúne problemas práticos: perdas, middleboxes, filtros incapazes de ver cabeçalhos de transporte e custos de remontagem.

Ele descreve mecanismos de fragilidade, não uma taxa universal de falha. Não prova que todo fragmento será bloqueado, que todos os roteadores tratam opções da mesma forma ou que tipos antigos permanecem comuns. Transformar avaliação arquitetural em censo seria exceder a fonte.

RFC 8200 mostra o contraste posterior: IPv6 deixa a fragmentação para a origem e separa de outro modo os cabeçalhos presentes em cada fragmento. A mudança ilumina a fronteira escolhida, mas não torna retrospectivamente inútil o bit IPv4. O desenho anterior precisava funcionar quando também um roteador intermediário podia fazer o corte.

Quem cortava recebia poderes estreitos

No IPv4, a origem ou um roteador pode fragmentar, dependendo do MTU, do caminho e de Don’t Fragment. Usar um roteador na cena inicial evidencia uma transformação feita longe do autor do conteúdo; não exclui a origem.

O poder do fragmentador é delimitado: dividir a carga, definir os campos de remontagem, selecionar opções conforme Copy, recompor alinhamento e checksum. Não pode reclassificar Record Route como irrelevante, atestar a veracidade de uma opção copiada ou prometer que o destino a aceitará.

A regra compartilhada contém apenas o necessário para que implementações independentes produzam fragmentos interoperáveis. O restante permanece com o participante que tem contexto: a origem escolhe opções; os roteadores processam conforme a especificação; o destino remonta e decide a versão autorizada.

Uma investigação deve preservar a árvore de derivação

Uma captura útil relaciona origem, destino, protocolo, Identification, Offset, MF, IHL, tipos, bits Copy e ordem de chegada. Ela testa violações específicas, não uma igualdade impossível. Copy 0 num fragmento não zero, ausência de Copy 1, opção truncada, alinhamento inválido ou teste preliminar nunca refeito são sinais diferentes.

Se o fragmento zero não apareceu, a ausência deve constar como limite. Não é prova de que o original não carregava Timestamp ou Record Route. Se cópias mutáveis divergem, é preciso verificar se a mutação era autorizada antes de concluir falsificação.

Preservar cada folha e a relação com o datagrama permite repetir a remontagem. Normalizar tudo para um único cabeçalho economiza espaço, mas remove justamente a evidência que explicaria por que os cabeçalhos eram diferentes.

Fontes e limite da evidência

Este artigo usa RFC 760, RFC 791, RFC 815, RFC 1122, RFC 1812, RFC 6274, RFC 8900, RFC 8200 e o registro IANA. Eles estabelecem regras e consequências delimitadas, não prevalência atual, conformidade de produto, incidência de ataques ou comportamento de todo caminho real.