Resumo

  • O contexto de remontagem é identificado por origem, destino, protocolo e Identification; um fragmento com offset diferente de zero já pode reservar memória e acrescentar bytes.
  • O timer deve eliminar o datagrama incompleto quando vence. Pela RFC 1122, a mensagem Time Exceeded é obrigatória somente se o fragmento zero foi recebido.
  • A ausência de ICMP é evidência negativa fraca. Ela combina perda do começo, limitação local, filtro, perda no retorno e diferenças de implementação numa mesma observação.

Um contexto sem começo ainda era contexto

RFC 791 descreveu a remontagem como uma caixa escolhida por quatro campos. O offset dizia onde copiar os dados; MF dizia se ainda haveria continuação. O offset zero identificava o primeiro fragmento, mas não determinava qual chegaria primeiro.

Se uma peça intermediária inaugurasse a caixa, o receptor alocava recursos. Se a última chegasse, MF em zero permitia calcular o comprimento. Mesmo assim, um buraco no início impedia a entrega ao protocolo superior. O sistema sabia bastante para gastar memória e saber que faltava algo, porém não bastante para produzir o datagrama original.

O procedimento guardava o cabeçalho numa área própria apenas quando FO = 0. Essa condição viria a importar também para o caminho de erro.

O timer começou como continuação do TTL

O exemplo de 1981 sugeriu quinze segundos como limite inicial inferior. Um fragmento novo podia elevar o timer ao seu TTL restante. O texto ligou diretamente taxa de dados, duração e tamanho de buffer: esperar mais significa financiar mais estado incompleto.

Mas TTL já funcionava como orçamento de saltos. Cada módulo o reduzia ao menos uma vez, mesmo sem decorrer um segundo. O valor recebido não era idade comparável entre caminhos. Usá-lo para decidir quanto tempo a memória local ficaria ocupada misturava duas autoridades: encaminhamento e recepção.

RFC 1122 desfez a mistura. O timeout deveria ser fixo, não derivado do TTL, com recomendação histórica de 60 a 120 segundos. Curto demais, eliminaria tráfego atrasado; longo demais, prenderia buffers e ampliaria a vida útil relevante do Identification.

Buracos compactos, ausência intacta

RFC 815 mostrou que bastava registrar os buracos restantes. Cada chegada cortava ou fechava descritores; nenhum buraco significava conclusão. A ordem dos fragmentos não era requisito.

As opções IP complicavam o cabeçalho. Algumas eram copiadas; outras existiam apenas no primeiro fragmento. Antes do offset zero, a forma completa do cabeçalho original podia ser desconhecida. Um algoritmo eficiente administra incerteza, mas não converte uma peça posterior no começo.

RFC 1122 acrescentou que o cabeçalho do primeiro fragmento precisa ser salvo para possível ICMP de timeout. A remontagem mantinha, assim, duas memórias: bytes para uma entrega que talvez ocorresse e contexto para uma explicação que talvez fosse necessária.

A resposta prometia citar o original

RFC 792 definiu Time Exceeded Type 11 Code 1. O corpo devolvia o cabeçalho IP original e os primeiros 64 bits de dados, material destinado a ajudar o emissor a associar o erro a um processo.

Fragmentos posteriores não são sem endereço. Eles carregam os campos usados na chave. O obstáculo é outro: seus dados não são os primeiros bits que a mensagem promete citar. Por isso a RFC limitou erros ICMP a fragment zero e disse que, sem ele, nenhum Time Exceeded precisava ser enviado.

O receptor ainda deve cuidar de si. RFC 1122 exige descartar o datagrama parcial quando o timeout vence. Se fragment zero foi recebido, exige também o ICMP. A primeira regra protege memória; a segunda protege a integridade do testemunho.

Nem todo roteador era o dono da espera

RFC 1812 esclareceu que um roteador, ao remontar pacote destinado a ele mesmo, atua como host. Isso não transforma cada hop de trânsito em reassembler. O contexto pertence ao destino que aceitou os fragmentos para si.

A mesma RFC proíbe erro ICMP como resposta a fragmento que não seja o primeiro, e essa proibição prevalece. Diagnóstico precisa separar o dispositivo que observou fragmentos daquele que realmente guardou o contexto até o vencimento.

Esperar também conserva uma identidade antiga

O Identification tem apenas 16 bits. RFC 6864 relacionou a janela de unicidade à vida máxima do datagrama e ao timeout. Enquanto pedaços antigos podem existir, reutilizar a mesma combinação aumenta o risco de misturar gerações.

O timer, portanto, não cobra só bytes. Ele prolonga a validade possível de uma associação. A conexão é relevante para o custo do estado, sem transformar este texto numa história geral do campo ID.

O primeiro pedaço levava consigo a explicação

Receber Code 1 permite uma conclusão estreita: o reassembler guardou um conjunto incompleto até expirar, possuía fragment zero e a mensagem atravessou o retorno. Não identifica a peça perdida ou o ponto da perda.

Não receber permite muitas hipóteses. O começo talvez nunca tenha chegado. O ICMP pode ter sido limitado, filtrado ou perdido. O produto pode divergir. Uma captura pode não ver tudo. O silêncio não demonstra conclusão nem ausência de fragmentos.

Isso produz viés operacional: falhas que preservam o começo têm maior chance de ganhar explicação; falhas que perdem o começo somem junto com a citação. Uma rede pode parecer mais saudável justamente onde o dano remove o mecanismo de relato.

Quatro silêncios com a mesma aparência

No primeiro silêncio, fragment zero não chegou. O destino expirou um contexto criado por partes posteriores e não tinha a condição normativa para Code 1. No segundo, zero chegou e o stack decidiu gerar a mensagem, mas um rate limit local a reteve. No terceiro, o pacote saiu e um filtro de retorno o descartou. No quarto, a mensagem chegou à máquina de origem, mas a coleta não a associou à tentativa correta.

Para quem observa apenas a aplicação, os quatro casos parecem iguais. A operação não recebeu dados completos nem explicação. Contudo, cada caso pertence a um proprietário diferente: caminho de ida, política do destino, caminho de volta ou observabilidade do emissor. Uma ação corretiva útil depende dessa separação.

O mesmo cuidado vale para o fragmento final. Receber MF zero prova onde aquele conjunto dizia terminar. Não prova que o emissor produziu todos os intervalos anteriores nem que um dispositivo específico os perdeu. Se final e zero chegam, os buracos internos ficam delimitados; se só final chega, falta também o contexto inicial da citação.

Code 1 não traz o MTU de um link nem nomeia um tunnel. RFC 1122 mencionou a possibilidade futura de usar o sinal em algum procedimento de descoberta, mas a mensagem isolada continua sendo um relato de timeout. Inferir tamanho correto, ponto estreito ou culpado exige outras observações.

Essa humildade é parte da confiabilidade. Um sistema que produz rótulos causais a partir de um único counter oferece uma resposta mais confortável, porém menos verdadeira, do que o protocolo permite.

A mudança de timer altera o conjunto observável

Ao aumentar a espera, alguns datagrams atrasados passam a completar e desaparecem do conjunto de erros. Outros contextos permanecem mais tempo sem nunca completar. A relação entre timeout e Code 1 pode cair mesmo com maior consumo de memória. Ao reduzir, mais contextos expiram cedo; se zero estava presente, a emissão potencial cresce, mas a aplicação pode sofrer mais.

Comparar antes e depois exige denominadores estáveis: contextos criados, conjuntos com zero, conjuntos com final, completions, expiries e evictions. Contar apenas mensagens recebidas confunde mudança de política com mudança de rede.

Também é preciso preservar a diferença entre recomendação e implementação. As RFCs explicam por que um valor fixo era preferível ao TTL e quais custos deveriam ser equilibrados. Não autorizam afirmar que qualquer sistema atual usa exatamente o intervalo recomendado ou mantém o mesmo algoritmo.

O relatório precisava permanecer contestável

ICMP não foi desenhado para tornar IP confiável. A própria RFC 792 avisa que datagrams e mensagens de controle podem desaparecer sem relato. Code 1 acrescenta feedback, mas não transforma o destino em árbitro do caminho.

Essa limitação importa quando equipes diferentes compartilham a mesma evidência. O time de aplicação vê uma operação que não terminou. O de rede vê fragments e talvez ICMP. O time do destino vê contextos e memória. Nenhuma visão isolada mostra a sequência inteira. Uma linha do tempo precisa preservar horários e vantage points, sem forçar todos a um relógio causal único.

Também não se deve atribuir a source address do fragmento a uma empresa ou contrato sem evidência externa. O campo orienta o protocolo; não prova quem controlava a máquina, qual rede perdeu bytes ou se o tráfego foi legítimo. A citação do pacote continua sendo dado técnico, não sentença institucional.

O ganho de guardar zero_received é justamente permitir uma linguagem mais precisa. Um operador pode dizer «o contexto expirou sem condição para Code 1» ou «era elegível, mas a mensagem não foi observada». Essas frases conduzem investigações diferentes e mantêm visível o que ainda falta demonstrar.

Na ausência dessa distinção, a organização tende a usar o resultado mais conveniente. Um emissor chama silêncio de sucesso do caminho; um destino chama ausência de ICMP de ausência de estado; um filtro chama queda de mensagens de redução de falhas. Todos confundem observabilidade com realidade.

A janela do teste também deve durar além do timeout avaliado. Se a coleta termina antes, contextos ainda vivos parecem eliminados e a comparação favorece prazos curtos. Mantenha comparáveis tamanho de datagram, classe de tráfego e mudanças de tunnel. Assim se distingue memória realmente recuperada de falhas apenas adiadas para depois do intervalo de medição. Registre o fechamento real de cada contexto, preserve separadamente a duração observada e documente a janela usada com precisão e contexto.

Fontes e limites

As fontes estabelecem regras e trade-offs. Não medem defaults atuais, frequência de fragmentação, entrega de ICMP, filtros ou conformidade de equipamentos.