Resumo

  • A RFC 2042 reservou o valor de tipo 255 para o desenvolvimento de novos atributos BGP. Para uso efetivo na Internet, o atributo deveria ser documentado em uma RFC, receber um type code único da IANA e ter documentação e código atualizados.
  • O texto rejeitou explicitamente divisões público/privado e Internet/OSI do espaço. Encontrar 255 não prova extensão proprietária, interoperabilidade, implantação, adoção, segurança, compatibilidade ou autorização.

Um número pode ser reservado sem ser exclusivo. Essa é a aparente contradição que organiza a RFC 2042: 255 era reservado para uma finalidade — desenvolvimento —, mas não para um desenvolvedor, fornecedor ou experimento específico.

Publicada em janeiro de 1997 como RFC Informational, a nota aparece hoje no fluxo Legacy do RFC Editor. O IETF Datatracker registra que ela não é endossada pela IETF e não possui posição formal no processo de padronização da organização. Sua autoridade é histórica e limitada: ela documenta uma fronteira de coordenação usada naquele período.

O marcador que não identificava o experimento

A RFC 1771 descrevia o BGP-4 e seus atributos de caminho. A RFC 2042 tratou de uma questão subsequente: como testar um novo tipo de atributo antes de receber um número público? A resposta foi usar o octeto 255 durante o desenvolvimento.

Dois protótipos incompatíveis poderiam fazer isso ao mesmo tempo. Um poderia esperar uma carga de tamanho fixo; outro, uma estrutura variável. A interpretação correta viria do acordo local, da versão do software e da configuração dos pares, não do 255. Em uma captura separada desses registros, o valor é ambíguo por definição.

Essa fraqueza evitava reservar códigos públicos para ideias efêmeras. Também estabelecia um limite: o protótipo não deveria tratar o marcador comum como identidade permanente. Quando o atributo fosse destinado ao uso real na Internet, ele precisaria de documentação em RFC e de um type code único atribuído pela IANA.

Depois da atribuição, o texto mandava atualizar tanto a documentação quanto a base de código. Não bastava ter uma linha no registro. O documento precisava nomear a nova identidade e o executável precisava colocá-la nos bytes emitidos.

Nenhuma seção privada estava sendo criada

A RFC 2042 afirma que não havia intenção de segmentar o espaço de códigos em seções públicas e privadas, nem em seções para Internet, OSI ou outros usos. Portanto, 255 não era um número de extensão de fabricante ou uma faixa empresarial comprimida em um único octeto. Era uma etiqueta temporária compartilhada.

O registro atual da IANA para BGP Path Attributes mantém 255 como “Reserved for development”, com referência à RFC 2042. A tabela não oferece uma faixa Private Use. Outras tabelas dentro da coleção BGP Parameters podem possuir políticas vendor-specific ou private-use, mas cada regra pertence ao registro que a nomeia. Não há herança automática entre tabelas apenas porque todas tratam de BGP.

Esse cuidado muda a leitura da evidência. “Valor 255” sem o nome do registro é uma descrição incompleta. Em Path Attributes, ele aponta para desenvolvimento; em outro subregistro, a política pode ser diferente. O número isolado não transporta sua governança.

A tabela contemporânea de Path Attributes também registra o procedimento Standards Action, citando a RFC 4271. A RFC 8126 define a terminologia moderna dessas políticas. Esse é o estado atual, não uma formulação que deva ser atribuída retroativamente à nota de 1997.

Registro não é execução

Uma atribuição da IANA prova que existe uma associação registrada entre número e significado sob determinado procedimento. Ela não prova que o código foi escrito, testado, distribuído ou habilitado. Muito menos demonstra que dois fornecedores chegaram à mesma interpretação ou que um operador autorizou a implantação.

A migração para fora de 255 deve ser observada em camadas. Primeiro, o registro e a especificação. Depois, o commit que troca a constante, os vetores de teste e o build. Em seguida, a implantação e o comportamento do par. Um documento atualizado com um binário antigo continua emitindo o marcador de desenvolvimento; um binário novo diante de receptores antigos pode encontrar rejeição apesar da atribuição legítima.

O princípio de Heng Lu sobre a primazia do código em funcionamento ajuda como lente editorial, não como requisito da IETF. Publicação e registro são fatos institucionais; um artefato compilado é fato executável; tráfego aceito é fato operacional. Subir de uma camada para outra exige observação adicional.

A errata corrige uma referência

A Errata ID 3681, única errata oficial da RFC 2042, corrige o número de uma referência: o documento sobre BGP Route Reflection é a RFC 1966, não a RFC 1998. Classificada como Editorial e mantida para atualização futura, ela não muda o processo nem o significado de 255.

O erro ortográfico visível em “documentation” não é o assunto da errata oficial. Registrar essa diferença evita atribuir ao sistema de erratas uma correção que ele não validou.

A fronteira que preserva o espaço comum

O desenho era econômico. Um único valor permitia desenvolvimento local; uma atribuição única permitia reconhecimento público. Entre ambos ficava uma passagem deliberada, na qual proposta, registro, documento e código deveriam se alinhar.

Chamar 255 de privado apaga essa passagem. Sugere que o experimento pode manter o valor e circular dentro de um domínio proprietário, quando o documento o trata como algo a abandonar antes do uso público. Também confunde isolamento operacional — que uma organização pode impor localmente — com uma categoria que o registro não concedeu.

A IANA pode dizer qual número identifica publicamente um atributo. Não pode dizer se ele funciona. E o 255 compartilhado nem sequer podia identificar, sozinho, qual experimento estava em curso.

Fontes