Resumo

  • A RFC 1476 colocou cinco decisões entre a chegada de uma oferta e sua visibilidade posterior: filtro de recepção, tratamento de métricas e opções, agregação, seleção ativa e filtro de transmissão por vizinho.
  • As classes de opção podiam preservar, retirar, confinar ou rejeitar uma rota; nenhuma dessas instruções autenticava o atributo nem provava encaminhamento ou entrega.

O mesmo nome escondia estados diferentes

A palavra “rota” aparece em um anúncio, numa base de candidatos, numa tabela ativa e numa mensagem enviada ao vizinho. Em RFC 1476, esses usos não eram equivalentes. O processo RAP recebia informações de pares, de interfaces, da configuração estática e de outros protocolos. Filtrava e organizava candidatos. Depois carregava apenas os escolhidos na base de encaminhamento IP. Por último, selecionava um subconjunto ativo para cada par.

RAP foi publicado em junho de 1993 como Experimental. Pretendia levar o vetor de distância de uma LAN isolada até redes de operadoras internacionais, deixando políticas locais definirem limites que outros modelos fixavam como interior e exterior. O registro do RFC Editor preserva a identidade e o status do documento. Não registra uma implantação.

O primeiro portão podia apagar uma oportunidade

O filtro de recepção limitava distância e especificidade. Um roteador pressionado por memória ou processamento podia fechar o filtro. A RFC observava um efeito temporal: se o operador o abrisse depois, uma oferta já descartada talvez nunca voltasse. O par podia não repeti-la.

A configuração recém-alterada é, portanto, uma capacidade de aceitar. Ela não é a presença do candidato. Para provar a rota depois da mudança, seria preciso receber outra atualização, conservar o anúncio anterior ao filtro ou disparar uma atualização. O estado administrativo não reconstitui o dado perdido.

A segunda etapa distribuía consequências da ignorância

O RAP atualizava distância, atraso, custo, MTU e largura de banda. Uma política conhecida podia rejeitar a rota. Para uma opção desconhecida, a própria opção levava uma classe de tratamento.

Classe 0: usar e propagar, mantendo a opção intacta. Classe 1: usar e propagar, mas sem a opção. Classe 2: usar localmente e não propagar. Classe 3: descartar a rota. Exceto pela distância do cabeçalho, nenhuma opção precisava ser compreendida por todas as implementações.

Era uma regra de interoperabilidade, não um selo de confiança. A classe não validava a origem nem o conteúdo. Tipo e classe eram independentes. O campo de formato podia permitir que um operador imprimisse os bytes de um tipo desconhecido, mas a forma legível não oferecia semântica. A classe 1 tampouco criava sigilo; o documento dizia que o tipo podia ser neutralizado antes de o restante seguir viagem.

O ponto não é repetir o contrato de opções IPv6 nem o atributo Partial do BGP, já tratados em outras matérias. No RAP, a consequência da opção desconhecida atravessava a arquitetura: uma mesma oferta podia sobreviver localmente e desaparecer da visão externa.

Restringir fonte não era o mesmo que impor uso aceitável

Source Restriction descrevia as origens autorizadas a utilizar a rota. Se o encaminhamento tivesse filtros de segurança, a informação precisava aparecer no anúncio para evitar que um tráfego escolhesse um caminho “melhor” e acabasse descartado sem resposta.

Representar o filtro também revelava algo sobre a política de segurança. A RFC reconhecia a possível confidencialidade e orientava propagação cuidadosa apenas em direção à rede autorizada. Esse desenho não prova que um produto real evitou vazamentos.

AUP carregava uma regra cooperativa de uso aceitável, como a exclusão de tráfego comercial. A própria RFC negava que fosse uma barreira de segurança. Public, por sua vez, avisava que algum meio de difusão no caminho podia ser lido por terceiros. Origem permitida, finalidade aceita e exposição do meio eram três perguntas diferentes.

O terceiro portão trocava detalhe por escala

Na agregação, rotas mais específicas podiam ser absorvidas por uma rota abrangente através do mesmo par. Mas a operação não era automática. Atributos de política podiam impedir o agrupamento ou eliminar a candidata. Manter detalhes também podia ajudar o identificador de rota do desenho TP/IX.

RFC 1338 documenta a pressão contemporânea por supernetting. A RFC 1476 mostra a contrapartida: reduzir estado pode retirar do próximo par as distinções de que ele precisaria para decidir. Um agregado recebido não é um inventário completo de seus componentes.

Ativar era uma quarta decisão

Depois da agregação, o RAP reunia candidatos próprios e rotas vindas de protocolos como RIP. A política local escolhia quais seriam carregadas na base de encaminhamento. RFC 1058 fornecia a referência de vetor de distância; RFC 1247, a de OSPF e estado de enlace.

Ter uma rota na base RAP ainda não dizia que ela estava ativa. Mesmo ativa, ela não provava que um pacote concreto combinou com a entrada, atravessou a interface ou chegou ao destino. O plano de controle podia explicar uma escolha; o plano de dados precisava de evidência própria.

Exportar era a quinta decisão

O filtro transmissor trabalhava somente com rotas ativas, mas podia produzir um conjunto diferente para cada par. Uma rota usada localmente podia ser invisível para um vizinho. Outra podia ser oferecida sem certo atributo. A visão externa era uma projeção da política do anunciante.

Havia uma obrigação adicional: filtros de datagramas precisavam ser representados na oferta para que vizinhos não enviassem tráfego a um buraco negro. Saber que a norma existia não prova que o filtro, o anúncio e a decisão remota ficaram alinhados.

TCP vivo, RAP talvez não

Os pares mantinham uma conexão TCP simétrica na porta 38 e trocavam comandos em duplex, sem confirmação individual. Poll e No Operation testavam atividade na camada RAP. A RFC desencorajava usar apenas o keepalive de TCP porque ele mostrava que TCP aceitava dados, não que o processo RAP remoto estava funcionando.

Quando a conexão caía, cada lado deveria remover todas as rotas oferecidas pelo outro. Esse dever ainda precisaria de logs para ser comprovado. A proteção final contra loops também era limitada: prometia rompimento eventual, não rápido, e não resolvia um erro que se repetisse continuamente.

Uma proposta que ensinava a pedir recibos

A RFC 1475 e seu registro descrevem o ambiente TP/IX. A matéria anterior já delimitou o identificador privado de próximo salto e a sequência Add/Purge. Aqui, a contribuição é outra: a rota atravessava autoridades locais distintas antes de ganhar efeito ou visibilidade.

RFC 2026 ajuda a manter a classificação documental separada da adoção. Experimental não significa irrelevante; também não significa implantado.

Essa leitura segue os ensaios de Heng Lu sobre primazia do código em operação, especificação mínima e decisão futura localizada e camadas de realidade. Uma mensagem recebida abre uma cadeia de escolhas. Não herda o efeito das escolhas que ainda não aconteceram.

Fontes