Resumo

  • A RFC 1118 partia de um site que já operava alguns hosts IP em uma Ethernet, mas ainda não estava conectado à Internet.
  • O texto orientava sobre endereçamento, escalonamento e serviços de informação, sem se apresentar como padrão ou tutorial.

O primeiro obstáculo para se conectar não era apenas técnico. Um campus podia ter hosts IP funcionando e ainda não possuir um número de rede exclusivo, não saber quem era o operador a montante ou não entender como suas decisões afetariam outras redes. Publicada em setembro de 1989, a RFC 1118 tratou dessa passagem. Seu leitor já administrava uma pequena rede isolada; a meta era conectá-la com pouco risco para os dois lados.

Esse limite moldou o documento. Ele não propôs um protocolo novo. Reuniu referências, leituras e dicas que, segundo o autor, normalmente não eram registradas. Explicava como entender a direção da Internet, onde buscar informação online e como agir como um bom vizinho de rede. O assunto era a transição da competência local para a participação em um sistema interconectado, não o formato de um pacote.

A operação aparecia como uma estrutura distribuída. ARPANET, NSFNET e as redes regionais tinham centros de operação próprios. Se um campus conectado a uma rede regional enfrentasse um problema, seu contato deveria procurar o operador ao qual estava ligado diretamente, mesmo que a rede regional alcançasse NSFNET e ARPANET por gateways. O caminho de escalonamento seguia a relação operacional real; não mandava o campus novo direto ao backbone mais conhecido.

A obtenção de endereços também fazia parte da entrada. A RFC descrevia uma solicitação ao SRI-NIC para obter um número de rede IP exclusivo. Tratava da alocação classful da época e da pressão sobre as tabelas de gateway conforme crescia o número de redes. A RFC 950 trazia o procedimento formal de sub-redes; a RFC 1009 definia requisitos para gateways. A RFC 1118 situava esses documentos nas decisões de um administrador de campus. Suas instruções sobre classes A, B e C e contatos do NIC são registros de 1989, não etapas atuais de conexão.

A segurança era recíproca. O guia dizia que a Internet fora projetada para cerca de 50 redes, mas se aproximava de 1.000, pressionando capacidade de gateways e causando congestionamento. Também observava que muitos gateways aceitavam informações de roteamento com base na confiança; um gateway hostil poderia causar danos sérios. Isso não prova que um ataque ocorreu. Mostra por que conectar uma rede envolvia obrigações além de tornar um host alcançável: um anúncio de rota podia afetar tráfego muito além do campus.

Os serviços de informação completavam o mapa. A RFC apontava para o SRI-NIC e distinguia serviços da BBN para CSNET e NSFNET dos serviços da Merit para NSFNET. Telnet, FTP, correio, listas de discussão e contatos de operação abriam caminhos diferentes. Não existia um balcão que respondesse a tudo; o recém-chegado precisava descobrir qual instituição tratava de cada assunto.

O aviso editorial era incomumente franco. A RFC 1118 dizia que não especificava padrões, reconhecia a edição desigual e brincava com seus próprios erros. Também previa atualizações regulares porque a Internet era dinâmica. Isso registra uma intenção de manutenção, não demonstra que todas as revisões foram feitas ou que todos os sites seguiram o guia. A RFC 1123, publicada no mês seguinte, formulou requisitos de aplicações e serviços de host em um gênero mais normativo; ela não transformou a RFC 1118 em protocolo nem apagou seu papel operacional.

O guia preserva uma camada que especificações podem deixar implícita: entrar na Internet exigia localizar um operador, obter um endereço, encontrar informação atual e entender o que as redes vizinhas esperavam. Admitir que o texto podia errar não tornava esse conhecimento inútil; tornava sua validade temporal parte do problema. Um manual para uma Internet em mudança precisava ser lido como um mapa datado a confirmar, e não como prova de que o caminho era seguro ou de que o site já havia chegado.

Fontes