Resumo

  • A RFC 3359 reuniu em uma lista comum valores TLV usados ou propostos no IS-IS para reduzir colisões, mas afirmou expressamente que não era norma nem autoridade de alocação.
  • A RFC 3563 transformou essa fotografia em ponto de partida para um registro temporário da IANA com revisão de especialista; uma linha registrada não comprova implementação ou implantação.

O conflito começa antes do pacote. Duas equipes podem escolher o mesmo número de oito bits para extensões diferentes sem que nenhuma delas tenha ignorado sua própria documentação. Quando os dois significados chegam a um roteador, o byte no fio não explica qual tabela privada deve prevalecer. A máquina interpreta segundo o software que recebeu. Uma decisão coerente em cada grupo pode produzir incompatibilidade quando os grupos se encontram.

Publicada como documento Informational em agosto de 2002, a RFC 3359 ofereceu uma memória comum para os valores TLV do IS-IS. O texto de T. Przygienda listou valores de nível superior já usados ou previstos e apontou se apareciam em IIH, LSP ou SNP. A tabela não definia a semântica de cada extensão; ajudava a próxima pessoa a escolher um espaço que talvez já tivesse dono operacional.

A mistura de referências revelava por que uma única lista era necessária. Entradas da ISO 10589 conviviam com as extensões IP da RFC 1195, propostas em documentos IETF, um valor DECnet descrito como antigo e códigos proprietários da Lucent e da Nortel. A presença lado a lado não tornava todas essas entradas equivalentes como padrão. Mostrava que caminhos institucionais diferentes já ocupavam o mesmo espaço numérico do protocolo.

A RFC foi direta sobre o limite de sua própria autoridade: queria evitar conflitos futuros, mas não constituía padrão nem órgão que atribuísse números TLV. A coordenação era informacional e compartilhada entre grupos da ISO, SIF e IETF. A ISO não oferecia uma autoridade de numeração, enquanto a responsabilidade da IANA era descrita como limitada a códigos relacionados a IP. O documento concluiu que não havia uma autoridade central plausível naquele momento.

Uma lista ainda pode influenciar uma decisão sem poder aplicá-la. Quem consulta uma entrada já ocupada ou em discussão pode escolher outro valor. O mecanismo é transparência, não sanção. A utilidade vem do interesse comum em evitar que implementações distintas atribuam ações diferentes aos mesmos bytes. A fonte não mede quantas colisões concretas foram evitadas; seu propósito era reduzir a chance de uma escolha às cegas.

Os limites da tabela eram importantes. A RFC 3359 não ligava cada valor ao documento exato que o definia e deixava os códigos de sub-TLV sem solução. Previa atualizações periódicas e admitia que um registro oficial poderia substituí-la. Uma linha servia como aviso de ocupação, não como histórico completo, regra de compatibilidade ou prova de suporte em software.

O mesmo ano trouxe a RFC 3232, que trocou a republicação periódica da lista geral Assigned Numbers por um banco de dados online. Para um espaço que muda, uma fonte continuamente atualizada pode ser mais útil do que esperar outro RFC. O IS-IS acrescentava uma fronteira institucional: a ISO mantinha o núcleo, enquanto a IETF desenvolvia extensões específicas da Internet; outras implementações já tinham seus próprios valores. A questão passou a ser quem mantém o registro, quem aprova uma alocação e como as organizações compartilham o estado.

Em 2003, a RFC 3563 documentou o acordo cooperativo entre ISOC/IETF e ISO/IEC JTC1/SC6. Ele delimitou o trabalho sobre o núcleo do IS-IS e as extensões da Internet e pediu que a IANA mantivesse provisoriamente o registro de TLVs até que a JTC1 fornecesse esse serviço. O caráter provisório importa: após notificação, a autoridade de alocação poderia ser transferida à JTC1, embora a IANA pudesse manter uma cópia informativa atualizada com dados recebidos dela.

Hospedar a página, autorizar uma alocação e manter a norma eram, portanto, funções distintas. O estado inicial do novo registro deveria ser sincronizado com a RFC 3359. A lista informativa tornou-se a base, não um erro a apagar. Novos números dependeriam da aprovação de um especialista designado pela IESG; a IETF deveria manter a JTC1/SC6 informada, e pedidos originados nessa comunidade seriam encaminhados ao processo IANA. O acordo transformou a comunicação entre instituições em parte do procedimento.

O esquema do registro também evoluiu. A RFC 6233 acrescentou a coluna Purge para identificar os TLVs permitidos em um LSP purgado. O contexto do PDU pode alterar se um valor é válido, embora a coluna continue sendo um resumo e a especificação que define o TLV contenha a regra completa.

A RFC 7370, de 2014, reuniu registros relacionados de sub-TLV e orientou a revisão por especialistas antes da publicação de um RFC. Em geral, uma solicitação deveria surgir de um documento adotado por grupo de trabalho; sem grupo apropriado, havia uma via patrocinada por um diretor de área. O especialista verificaria consenso ou aprovação, avaliaria o mérito técnico sem se sobrepor ao consenso IETF e poderia aplicar prazo e devolução do valor se o documento não avançasse.

A RFC 7120 apresenta a disciplina geral para alocações antecipadas; a RFC 7370 explica sua aplicação aos registros Expert Review do IS-IS. A RFC 8126 organiza nomes de políticas de registro, mas uma política aprovada não certifica que uma implementação existe. Em 2024, a RFC 9650 mudou um registro de bits de atributo de enlace de Standards Action para Expert Review. A regra anterior dificultava a alocação experimental e podia estimular o uso não registrado de valores. Controles frouxos favorecem colisões; controles excessivos podem expulsar a experimentação do registro compartilhado.

A página atual da IANA é o resultado vivo dessa evolução: inclui registros aninhados, campos de aplicabilidade a PDU, referências e procedimentos que não constavam da tabela de 2002. Esta pesquisa trata a página como um recorte datado, não como descrição retroativa do que a RFC 3359 continha.

Uma linha atual prova apenas que valor, nome, referência e política estão associados no cadastro. Não demonstra suporte no parser, configuração ativa, interoperabilidade entre fabricantes, instalação de rota ou entrega de pacote. Entre o código atribuído e um resultado de rede existem evidências diferentes: implementação, configuração, troca entre pares e comportamento observado.

Fontes