Resumo
- A RFC 917 era uma proposta, não um padrão; ela registrou sub-redes IP em Stanford desde o início de 1982, com cerca de 330 hosts e 18 sub-redes em 1984.
- Stanford alinhou as sub-redes IP aos números de rede Pup existentes. A RFC 917 propôs uma largura escolhida por rede; a RFC 950 padronizou procedimentos de host em 1985.
O dado mais concreto da RFC 917 é também o que mais facilmente vira uma história errada: cerca de 330 hosts, 18 sub-redes e quase o mesmo número de gateways em Stanford. A contagem descreve um local em 1984, não a Internet inteira. Jeffrey Mogul publicou a RFC em outubro daquele ano como proposta para discussão e aperfeiçoamento. O texto informa que as sub-redes IP de Stanford já funcionavam desde o começo de 1982.
O projeto partiu de uma rede que já tinha memória operacional. Desde 1979, Stanford usava Pup em várias Ethernets experimentais. Com a introdução do IP, adotou um número de sub-rede de oito bits, igualando cada sub-rede IP ao número de rede Pup da Ethernet correspondente. Os números Pup de host, também de oito bits, foram reaproveitados no campo de host do IP. Em vez de substituir todo o mapa, a equipe o traduziu para uma camada de endereçamento nova.
As rotas seguiram a mesma lógica. As tabelas IP eram mantidas pelo processo que atualizava as tabelas Pup, com conversão dos números de rede. Gateways que só conheciam Pup encaminhavam datagramas IP usando as rotas Pup, mas não mexiam no Time-to-Live do cabeçalho IP. Hosts com várias interfaces que funcionavam como gateways faziam esse ajuste. Mogul relata que não haviam surgido problemas de loop naquela instalação; o relato não sustenta uma regra geral para ignorar TTL.
Quando Stanford adicionou Ethernets de 10 Mbit/s, modificou os gateways para usar um mecanismo baseado em ARP. Isso permitiu conectar hosts sem alteração. A experiência mostra que ampliar uma rede existente era tanto um problema de compatibilidade com equipamentos em uso quanto de desenho de endereço.
O MIT fez outra divisão. Como a instituição acumulava muitos enlaces antes de os números de rede IP serem classificados, dar um número a cada enlace teria consumido uma parcela considerável do espaço disponível. O MIT manteve um único número de rede e dividiu os 24 bits restantes em três campos de oito: sub-rede, reservado e obrigatoriamente zero, e host. O byte de sub-rede correspondia ao de CHAOS. Um protocolo dinâmico entre gateways chegou a ser planejado, mas não foi implementado; as tabelas continuaram estáticas. Redirecionamentos ICMP de host reduziram as mudanças no software dos computadores.
A RFC 917 comparou quatro formas de codificar o campo: largura variável, largura fixa e duas formas autoidentificadas. Sua proposta escolheu uma largura variável, constante dentro de cada rede e diferente entre redes quando necessário. Os esquemas autoidentificados poderiam revelar a subdivisão olhando apenas o endereço, mas ameaçavam números de host já usados e diminuíam o espaço local. Cabia a cada organização escolher quantos bits reservar para sub-redes.
Também era necessário que uma estação recém-iniciada descobrisse essa largura. A RFC 917 propôs mensagens ICMP Address Format Request e Address Format Reply, especialmente úteis para estações sem disco, sem impedir configurações locais persistentes. Se nenhum gateway respondesse, o host podia assumir largura zero e corrigir a interpretação quando recebesse a largura real. Essas mensagens não são as posteriores Address Mask da RFC 950.
Em abril de 1985, a RFC 940 explicou por que fornecedores precisavam de um esquema comum: hosts de fabricantes diferentes poderiam discordar sobre enviar diretamente ou usar um gateway. A RFC 950, em agosto, declarou basear-se na RFC 917 e recomendou um procedimento comum para hosts; não definiu por completo a comunicação entre gateways. A ordem importa: redes locais primeiro, proposta depois, padronização em seguida.
A Nota 64 de Heng Lu funciona aqui como lente editorial para pensar regras mínimas compartilhadas e escolhas locais. Ela não é evidência da intenção de Mogul, Stanford, MIT ou Postel.
- Fonte: RFC 917, “Internet Subnets” (October 1984): https://www.rfc-editor.org/rfc/rfc917.html
- Fonte: GADS, RFC 940, “Toward an Internet Standard Scheme for Subnetting” (April 1985): https://www.rfc-editor.org/rfc/rfc940.html
- Fonte: Jeffrey Mogul and Jon Postel, RFC 950, “Internet Standard Subnetting Procedure” (August 1985): https://www.rfc-editor.org/rfc/rfc950.html
- Contexto: Jon Postel, RFC 791, “Internet Protocol” (September 1981): https://www.rfc-editor.org/rfc/rfc791.html
- Heng Lu, Note 64 (interpretive lens only): https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
