Resumo

  • A RFC 1201 permitia que um datagrama atravessasse até 120 quadros ARCNET, com no máximo 504 octetos de dados de cliente por quadro longo.
  • O limite de 60.480 octetos não definia o MTU de uma rede; o máximo precisava ser configurável e compatível entre os equipamentos daquele enlace.

O custo de evitar a fragmentação

A RFC 1201 apontava 504 octetos como um tamanho IP capaz de evitar a fragmentação na camada de enlace ARCNET. A escolha reduzia a necessidade de remontar várias partes, mas exigia que cada nó pelo caminho processasse mais pacotes IP. Não havia uma vitória sem custo: um datagrama maior consumia fragmentação, memória e trabalho de remontagem; pacotes menores elevavam sua quantidade.

Essa escolha só fica clara quando se separa tamanho do quadro e tamanho do datagrama. O quadro ARCNET longo tinha 512 octetos, mas cabiam no máximo 504 octetos de dados de cliente depois dos cabeçalhos e do preenchimento usados para completar o quadro fixo. O curto tinha 256 octetos. Para dados de cliente de 250, 251 ou 252 octetos, havia um quadro de exceção. A capacidade física era uma restrição concreta, não um MTU IP pronto.

RFC 1201 mudou a camada de fragmentação

A RFC 1051, publicada em 1988, transportava IP e ARP no formato ARCNET anterior. Quando nem todos os hosts suportavam quadros estendidos, recomendava MTU IP de 253 octetos e incentivava fragmentação na camada IP. A RFC 1201, de fevereiro de 1991, substituiu essa especificação e deixou a camada de enlace dividir o pacote.

Uma flag de divisão indicava se o pacote era inteiro, se aquele era o primeiro fragmento ou se era uma parte posterior. Um número de sequência comum ligava as partes. O formato admitia até 120 fragmentos, ou 60.480 octetos. Mas a RFC chamou esse tamanho de impraticável e exigiu que o máximo fosse configurável. Os nós de uma rede ARCNET precisavam concordar em um valor menor que todos pudessem receber. O documento exigia suporte a datagramas de pelo menos 576 octetos e recomendava fortemente 1.500; isso é uma exigência de implementação, não prova do MTU configurado em uma instalação.

A remontagem tinha estado e prazo

Como os fragmentos eram enviados em ordem, o receptor podia desistir se algum chegasse fora de sequência. A RFC recomendava reservar, na chegada da primeira parte, espaço suficiente para o pacote completo. Se nenhum fragmento novo aparecesse por alguns segundos, a remontagem incompleta também poderia ser descartada. Já um fragmento repetido deveria ser ignorado: a placa ARCNET podia receber o quadro sem que o reconhecimento voltasse ao emissor, que então o retransmitiria.

Isso separa a confirmação de um quadro da entrega de um datagrama completo. RFC 791 define o datagrama e a fragmentação IP; RFC 826 dá o contexto do ARP. A RFC 1201 descreve a fronteira específica de ARCNET, sem relatar captura, taxa de repetição ou sucesso de uma aplicação.

Para anunciar tamanhos menores, o texto menciona a opção MSS do TCP e mecanismos de descoberta de MTU, citando RFC 1063. A RFC 1191 trata depois a descoberta de MTU de caminho IPv4; ela não comprova que uma interface ARCNET usou certo limite ou que um pacote chegou ao destino.

Compatibilidade não vinha do cabo

A RFC 1201 conta que cinco empresas haviam concordado, em 1989, em usar o formato de enlace ARCNET associado à nova especificação. Os identificadores eram 212 para IP, 213 para ARP e 214 para RARP, diferentes dos valores definidos pela RFC 1051. As duas encapsulações podiam coexistir em uma mesma rede, mas não se comunicavam. Manter o mesmo meio físico não tornava o formato antigo e o novo intercambiáveis.

O RFC Editor cataloga hoje a RFC 1201 como STD 46, Internet Standard. Esse registro demonstra o status do documento, não quantos equipamentos o implementaram. O relato histórico que o texto permite afirmar é mais estreito: um meio de quadros fixos recebeu um mecanismo de fragmentação na camada de enlace, o tamanho máximo permaneceu uma decisão configurável e a mudança de identificadores delimitou quais estações podiam conversar.

Fontes