RFC 3115: quando o código em operação decidiu os números

Resumo

A RFC 3025 imprimiu 37 para a extensão crítica CVSE e 133 para a normal NVSE. A IANA registrou 38 e 134. A RFC 3115 tornou o texto de fevereiro obsoleto em abril porque as implementações correntes seguiam a IANA.
O tipo externo escolhia o destino de uma mensagem desconhecida: abaixo de 128, descartava-se tudo em silêncio; a partir de 128, o receptor podia pular a extensão e continuar.

A correção de dois números era uma correção de comportamento

Uma solicitação de registro do Mobile IP podia carregar informação que apenas um fabricante entendia. O protocolo precisava decidir o que fazer quando essa informação chegasse a outro equipamento. Havia duas respostas possíveis: interromper a mensagem inteira ou ignorar somente a parte privada.

A RFC 2002 codificou essa política no próprio espaço de tipos. Extensões desconhecidas entre 0 e 127 eram não ignoráveis: o receptor descartava silenciosamente a mensagem. Entre 128 e 255, usava o campo Length para passar sobre os bytes desconhecidos e continuava processando o restante.

Foi nesse limite que surgiu a divergência. A RFC 3025, publicada em fevereiro de 2001, definiu a Critical Vendor/Organization-Specific Extension, CVSE, como tipo 37 e a Normal Vendor/Organization-Specific Extension, NVSE, como 133. O repositório da IANA registrava 38 e 134.

Em abril, a RFC 3115 expôs as duas diferenças numa nota editorial e substituiu a RFC 3025. O motivo não foi uma preferência estética. O texto informou que as implementações correntes seguiam as atribuições da IANA.

Essa frase é evidência operacional, mas não é um censo. As fontes não identificam produtos, versões ou quantidade de instalações; também não descrevem um incidente causado pelo conflito. Elas permitem uma conclusão mais estreita: o comportamento implementado pesou o suficiente para que o registro normativo fosse corrigido.

Crítico e normal mediam o custo da ignorância

CVSE 38 ficou na faixa que não podia ser pulada. NVSE 134 ficou na faixa que podia. “Crítico” não significava mais importante para o negócio; significava que o restante da mensagem não devia ser interpretado sem aquela extensão. “Normal” dizia que a função privada podia se perder sem invalidar necessariamente todo o intercâmbio.

Tanto 37 quanto 38 estavam abaixo de 128, e 133 e 134 estavam acima. A discrepância não trocou uma política pela outra, mas quebrou a identificação exata. Um parser preparado para 38 que recebesse 37 via outro tipo crítico desconhecido e eliminava a mensagem. Um parser preparado para 134 que recebesse 133 podia ignorá-lo e seguir, produzindo um aparente sucesso sem a função desejada.

O primeiro defeito parecia perda de pacote. O segundo podia parecer sucesso parcial. Nenhum deles era bem explicado por um único campo “registration succeeded”. Era necessário registrar o byte recebido, a constante reconhecida e a decisão tomada.

“Silently discard” também tinha limites. O receptor não continuava nem enviava erro ao remetente, mas deveria conseguir registrar o evento, incluir o datagrama descartado e aumentar um contador. Para o emissor, havia silêncio; para o operador do receptor, deveria existir prova. Se essa prova fosse perdida, timeout, falha de autenticação e incompatibilidade de tipo se confundiriam.

Havia duas etapas de reconhecimento

Uma entidade podia desconhecer o tipo externo 38. Também podia reconhecer a estrutura CVSE e, depois de abri-la, não entender o Vendor/Org-ID ou o Vendor-CVSE-Type. A RFC 3115 tratava essas situações de maneira diferente.

No primeiro caso, a regra geral da faixa 0–127 descartava a mensagem sem resposta. No segundo, o receptor já sabia localizar os campos e a falha ganhava uma resposta explícita. Uma solicitação com CVSE conhecido por fora e desconhecido por dentro devia ser negada com código adequado.

Numa resposta, o papel do nó importava. Se ele era trânsito para outra entidade, emitia uma rejeição adiante. Se era o destinatário final, tratava a resposta como rejeitada. Para NVSE, um número de empresa ou subtipo desconhecido fazia o receptor pular a extensão e continuar.

Por isso, a expressão “extensão de fornecedor desconhecida” é insuficiente. Um diagnóstico fiel preserva tipo externo, versão do parser, reconhecimento do envelope, enterprise number, subtipo, sentido, papel do nó, validação de comprimento, ação escolhida e eventual código de negação. Uma constante antiga e uma capacidade privada ausente não são a mesma falha.

O namespace privado não carregava autoridade total

Os dois formatos usavam um Vendor/Org-ID de quatro octetos. O octeto alto era zero; os três baixos continham o SMI Network Management Private Enterprise Code. A organização administrava então um subtipo de dois octetos e seu valor.

O arranjo dividia custódia. A IANA atribuía os tipos externos e códigos de erro. O registro de enterprise numbers vinculava o espaço a uma organização. A organização definia subtipos. O emissor escolhia extensões. O receptor escolhia o que implementava. As associações de segurança do Mobile IP autenticavam mensagens quando exigido. A política local ainda aceitava ou negava o serviço.

Um enterprise number não autenticava o remetente. Uma mensagem autenticada não explicava um subtipo novo. Reconhecimento não era autorização. Registro aceito não provava que o tráfego do usuário havia começado.

A RFC 3115 permitia vários CVSEs e NVSEs depois da parte fixa e dizia que nós intermediários não deveriam mudar sua ordem. Ordenar TLVs ao armazená-los pode parecer uma normalização inocente, mas perde a sequência que o emissor criou, que o autenticador cobriu e que cada parser recebeu.

A seção de segurança assumia a autenticação prevista no Mobile IP e não criava requisitos extras. Essa era a premissa do documento, não prova de que todo caminho implantado estivesse autenticado ou de que o conteúdo privado fosse seguro. Resultado criptográfico, suporte semântico e decisão de política continuam fatos distintos.

Quatro códigos guardaram a direção da falha

Os códigos 100 e 101 pertenciam ao foreign agent. O 100 indicava Vendor-ID ou subtipo crítico vindo do mobile node que ele não compreendia; o 101, conteúdo vindo do home agent. Os códigos 140 e 141 pertenciam ao home agent e distinguiam a origem no mobile node ou no foreign agent.

Os números localizavam o intérprete e parte da proveniência. Não diziam o significado do valor privado, não provavam que a negação chegara ao mobile node e não descreviam o resultado posterior do serviço. Um nó de trânsito podia receber uma resposta válida para o home agent, falhar ao entender o CVSE e produzir outra rejeição para o próximo trecho.

Olhar somente um participante cria uma narrativa incompleta. A cadeia precisa do pedido original, extensões em ordem, decisão de cada agente, resposta transformada, estado final de registro e tráfego observado depois.

O registro on-line virou parte do sistema

A RFC 1700 foi uma fotografia de Assigned Numbers em 1994. A RFC 3232 declarou em 2002 que bancos on-line da IANA haviam substituído essas fotografias e que a RFC 1700 estava incompleta e às vezes errada. A RFC 3115 capturou a transição um ano antes.

O registro vivo podia acompanhar atribuições. O RFC podia explicar estrutura e comportamento, mas congelava no momento da publicação. Nenhum bastava sozinho. A IANA tinha 38 e 134, sem toda a semântica de trânsito e rejeição; a RFC 3025 tinha a semântica, mas números divergentes.

O registro atual Mobile IPv4 Numbers mantém 38, 134 e os quatro códigos, com referência à RFC 3115. Isso prova o estado presente, não cada edição histórica. A história exige também as cópias congeladas das RFCs 3025 e 3115.

Especificar um uso não mede adoção

A RFC 4332 definiu extensões Cisco para prefixo da rede doméstica, gateway, DNS, DHCP e URL de configuração. A RFC 4784 definiu três extensões Verizon Wireless com tipo 38 e enterprise number 12951 para uma atualização dinâmica de chaves em redes cdma2000.

São usos específicos e documentados. Não medem instalações, pacotes, êxito de interoperabilidade ou alcance comercial. Uma obrigação escrita não é uma execução observada.

A RFC 5612 reservou depois o enterprise number 32473 para exemplos. Até dados fictícios precisavam de um espaço incapaz de colidir com organizações reais, pois exemplos migram para código, testes e capturas. A RFC 6709 generalizou o risco: extensões privadas oferecem flexibilidade, mas revisão fraca e comportamento mal definido para desconhecidos expõem interoperabilidade, operação e segurança.

A RFC 3115 já tornava a escolha concreta. Ignorar o crítico perdia a mensagem. Ignorar o normal perdia a função. Corrigir os tipos restabeleceu acordo sobre qual custo cada extensão impunha.

Código em operação era testemunha, não autoridade absoluta

O episódio não afirma que qualquer implementação prevalece sobre qualquer norma. Código pode estar errado; registros e RFCs também mudam. A decisão foi limitada: a autoridade de atribuição discordava do texto, e o próprio substituto registrou que implementações seguiam a autoridade.

Uma captura provaria emissão, não interpretação. Um log de parser provaria uma decisão local, não o registro final. Um código provaria uma negação protocolar, não a experiência do usuário. “Implementações correntes” é mais forte que intenção de projeto e mais fraco que inventário universal.

Com essa disciplina, a sequência basta. A RFC 3025 imprimiu 37 e 133. A IANA atribuiu 38 e 134. A rede já usava o segundo par. A RFC 3115 não apagou a norma; corrigiu-a à luz de uma realidade que o fio havia preservado.

O RFC dizia 37. A rede já usava 38: RFC 3115

Por que isso importa

Resumo

A correção de dois números era uma correção de comportamento

Crítico e normal mediam o custo da ignorância

Havia duas etapas de reconhecimento

O namespace privado não carregava autoridade total

Quatro códigos guardaram a direção da falha

O registro on-line virou parte do sistema

Especificar um uso não mede adoção

Código em operação era testemunha, não autoridade absoluta

Fontes

Contexto aprofundado do perfil

Strategic Circle

Leadership Alliance

Briefing do Strategic Circle

Briefing da Leadership Alliance