Resumo

  • RFC 948 apresentou duas formas de carregar IP em redes físicas IEEE 802.3. Na primeira, um campo do cabeçalho conserva o papel de tipo de protocolo do Ethernet; na segunda, o IP entra no formato lógico IEEE 802.2. O mesmo fio pode transportar as duas formas sem que os respectivos computadores se entendam.
  • Ira Winston recomendou uma escolha estática de encapsulamento em todos os equipamentos e uma transição em duas etapas: todos permanecem no formato compatível com Ethernet enquanto se preparam; só então a rede inteira muda. Um gateway bilíngue resolveria parte da divisão com custo significativo de desempenho.

O fio não lê cabeçalhos

A incompatibilidade morava em dois bytes. No Ethernet Version 2.0, o campo diz qual protocolo vem dentro do quadro. No IEEE 802.3, a posição correspondente informa comprimento. RFC 948 observou que as camadas físicas eram compatíveis na prática, mas as camadas de enlace não. O sinal chegava pelo cabo; o receptor precisava saber qual gramática usar. Um conector bem encaixado não tomava essa decisão.

A primeira saída preservava a população instalada de computadores Ethernet. No caso 802.3 de 10 Mbit/s tratado pelo memo, o comprimento permitido chegava a 1500. Valores superiores podiam receber uso privado. Os tipos usados para IP, ARP e encapsulamento com trailer estavam acima desse número, de modo que o campo podia continuar funcionando como tipo de protocolo em quadros compatíveis com Ethernet sobre uma conexão física 802.3. Era uma engenharia de convivência com o parque existente, não um acordo entre os dois formatos.

A segunda saída usava LLC Type 1 Unnumbered Information de 802.2/802.3. O documento punha DSAP e SSAP em 96, o SAP global atribuído ao IP naquela proposta. O quadro podia receber zeros para cumprir o mínimo físico de 802.3, mas esses zeros ficavam fora do datagrama IP. Para relacionar endereços IP aos endereços da rede local, Winston admitia tabela fixa e recomendava com força descoberta dinâmica semelhante a ARP. Uma máquina que falasse esse formato podia trocar IP com outra igual. A vizinha que seguisse no quadro Ethernet lia outra coisa.

A última máquina da migração

A conclusão de RFC 948 não suavizava o resultado de misturar métodos: o LAN se tornaria duas sub-redes incompatíveis. Um host que compreendesse ambos poderia funcionar como gateway, mas o documento avisava que isso traria penalidade de desempenho significativa. O tráfego entre dois computadores presos ao mesmo cabo passaria por um intermediário por causa de uma diferença na moldura do pacote.

Winston preferia o caminho IEEE 802.2/802.3 pela aceitação nacional e internacional dos padrões e pela possibilidade de reutilizá-lo em outras redes físicas IEEE 802. O problema era o tempo. Já havia instalações Ethernet em uso. Sua sequência começava dando aos sistemas novos uma opção estática entre os formatos e atualizando os antigos para oferecer a mesma escolha. Durante essa preparação, todos continuariam no método compatível com Ethernet. A mudança para o método IEEE só viria quando todos pudessem realizá-la. O último computador importava tanto quanto a primeira interface nova.

A especificação de 1988, RFC 1042, usou LLC/SNAP, com DSAP e SSAP 170, código de organização zero e EtherType, em vez do SAP 96 direto da proposta de 1985. Ela também descreveu a consequência do cabo misto: broadcasts de enlace chegavam somente às máquinas do mesmo formato. Se a mistura fosse necessária, recomendava tratá-las como redes IP separadas por gateway. A publicação posterior mostra que a escolha de cabeçalho evoluiu e que o limite de interoperabilidade persistia. Ela não documenta uma implantação específica do cronograma de Winston.

O custo que RFC 948 deixou à vista era administrativo e técnico ao mesmo tempo. Alguém precisava saber quais máquinas já podiam falar as duas gramáticas, manter o idioma antigo comum durante a preparação e escolher uma janela de troca. Sem essa coordenação, o cabo continuaria inteiro enquanto a rede se partia.

Fontes