Resumo

  • A RFC 5308 usa o TLV 236 para alcance IPv6, o TLV 232 para endereços IPv6 de interface e o NLPID 142 para declarar suporte ao protocolo. São três afirmações com escopos diferentes, não um comprovante único de encaminhamento.
  • Na topologia padrão compartilhada, um caminho aprovado pelo SPF precisa ser associado à capacidade IPv6 de cada nó de trânsito, ao RIB, ao FIB e ao resultado do pacote. A RFC 5120 pode separar a participação por topologia, mas também não transforma controle em entrega.

O padrão silencioso da topologia compartilhada

É fácil ler uma rota IPv6 na base de estado de enlace como se ela tivesse herdado todas as propriedades do grafo que a transporta. O prefixo está presente, a métrica passa pelas regras, o SPF escolhe um predecessor e o próximo salto parece estável. Em uma operação dual stack, essa sequência costuma terminar em uma luz verde.

O problema aparece no meio. Um roteador pode pertencer à topologia IS-IS padrão e formar uma adjacência legítima, sem oferecer a capacidade IPv6 que aquela rota pressupõe em uma interface, contexto de roteamento ou geração de FIB específica. As pontas podem estar corretas e o cálculo também; ainda assim, o primeiro pacote pode encontrar um nó de trânsito que só realiza a metade IPv4 do acordo implícito.

Não se trata de atribuir à RFC 5308 um incidente que ela não relata. Trata-se de observar a fronteira criada pela combinação da RFC 5308 com a RFC 5120. A primeira permite transportar informações IPv6 junto de IPv4 e OSI. A segunda permite que operadores construam topologias distintas quando precisam tornar a participação explícita. Sem essa separação, adjacência significa conectividade IS-IS, não igualdade automática de capacidade entre famílias de endereços.

O TLV 236 responde sobre o prefixo

O TLV 236, IPv6 Reachability, contém um prefixo, uma métrica de 32 bits, os bits U, X e S e, quando indicado, sub-TLVs. O bit U registra a propagação descendente na hierarquia. O X marca uma origem externa, redistribuída de outro protocolo. O S informa que há um bloco de sub-TLVs. Nenhum desses bits declara que um pacote atravessou o caminho.

O TLV pode ocorrer zero ou mais vezes em um LSP. Prefixos link-local não podem ser anunciados por ele. Os bytes do prefixo são compactados ao tamanho mínimo determinado pelo comprimento, o que obriga um coletor confiável a preservar tanto o comprimento como os bytes significativos, em vez de guardar apenas uma apresentação textual normalizada.

A métrica introduz uma separação ainda mais clara. A RFC 5308 usa MAX_V6_PATH_METRIC, 0xFE000000. Um prefixo anunciado com valor superior não deve participar do cálculo SPF normal. Ele continua podendo existir no banco de dados por outro motivo. Logo, presença no LSP, aceitação sintática e elegibilidade para seleção são estados diferentes por definição normativa.

O TLV 232 responde sobre o endereço no contexto do PDU

O TLV 232 carrega endereços IPv6 de interface, mas seu significado depende de onde aparece. Em um Hello, deve conter apenas endereços link-local atribuídos à interface emissora. Em um LSP, deve conter apenas endereços não link-local atribuídos ao sistema intermediário que faz o anúncio.

Uma plataforma que extrai apenas o endereço e descarta o tipo de PDU perde a fronteira de autoridade do dado. Um endereço válido apenas no enlace pode parecer uma identidade de domínio; um endereço do sistema pode se tornar um valor sem origem verificável. Em ambos os casos, o dado está correto, mas a interpretação deixou de ser.

Por isso, a evidência operacional deve manter emissor, interface, PDU, escopo, instante e geração da base. A normalização que facilita uma busca não pode destruir a informação necessária para interpretar o registro depois.

O NLPID 142 declara suporte, não execução

Um sistema que oferece roteamento IPv6 por IS-IS deve incluir o NLPID 142 no TLV Protocols Supported. Entre os três sinais, este é o que mais diretamente fala da capacidade do processo de roteamento. Mesmo assim, a declaração não certifica toda a cadeia de encaminhamento.

Ela não prova que uma placa de linha específica recebeu a programação atual, que o vizinho link-local foi resolvido, que o RIB correto foi escolhido para o contexto, nem que uma política local não descartará o pacote. Também não torna todos os membros ECMP equivalentes. Um teste bem-sucedido pode ter usado justamente o único membro saudável.

Autenticar o LSP protege a origem e a integridade da afirmação. Não amplia seu escopo. Uma mensagem autêntica pode descrever corretamente um prefixo e uma adjacência enquanto o próximo salto selecionado carece da entrada IPv6 necessária no FIB. “Quem disse” e “o que o pacote encontrou” continuam sendo perguntas diferentes.

O inventário precisa acompanhar o caminho escolhido

Na topologia integrada, a segurança depende de um invariante que não está contido no grafo bruto: todo nó que pode ser escolhido como trânsito para IPv6 deve possuir a capacidade aplicável no plano de controle e no plano de dados. Um campo global “IPv6 habilitado” é uma aproximação fraca para esse requisito.

O vínculo útil é específico à rota. Ele associa o predecessor e o próximo salto escolhidos à interface, ao contexto de roteamento, à versão do software, à geração do RIB, à geração do FIB e a uma observação de pacote. Se houver ECMP, a regra cobre todos os membros elegíveis, não apenas aquele que uma sonda ocasional percorreu.

Isso muda o desenho do monitoramento. “Rota aprendida” não deveria esconder a sequência composta por: observada no LSP, analisada sem erro, elegível para SPF normal, preferida, resolvida, instalada no RIB, programada no FIB e comprovada por entrega. Cada transição tem um responsável e uma forma diferente de falhar.

A RFC 5120 torna a participação uma escolha visível

A RFC 5120 anuncia participação em topologias nos IIHs. Em um enlace ponto a ponto, se o vizinho não anuncia um determinado identificador, o roteador local não deve incluí-lo no LSP daquela topologia. Dois roteadores sem qualquer topologia em comum não deveriam formar adjacência. O MT ID 2 é reservado ao roteamento IPv6, e o TLV 237 acrescenta a associação à topologia antes do formato de alcance herdado do TLV 236.

A regra de LAN broadcast evita uma simplificação excessiva. Ali, roteadores ainda estabelecem adjacência mesmo sem uma multitopologia comum, para que todos elejam o mesmo DIS. A adjacência base permanece real, mas a capacidade de usá-la em uma topologia precisa ser decidida pela associação efetivamente compartilhada.

Separar IPv4 e IPv6 pode impedir que um nó incompatível entre como trânsito IPv6. Em troca, surgem estados adicionais: associação, overload por topologia, anúncios TLV 237, cálculos SPF e possivelmente RIBs separados. Quando topologias da mesma família usam endereços sobrepostos na mesma interface, a RFC 5120 exige outro mecanismo local para escolher o RIB do pacote recebido. O protocolo explicita a diferença; não toma sozinho a decisão de encaminhamento.

Uma correção posterior mudou a leitura da preferência

A RFC 5308 originalmente listou a preferência de rotas IPv6 como Level 1 up, Level 2 up, Level 2 down e Level 1 down. A RFC 7775 observou depois que o modelo subjacente de dois níveis não possui o tipo Level 2 inter-area necessário para sustentar aquela classe “Level 2 down”. A preferência foi substituída por regras alinhadas aos tipos realmente suportados para os TLVs 236 e 237.

Uma revisão contemporânea de implementação deve, portanto, considerar a RFC 7775, não congelar a lista de 2008. O registro também deve preservar TLV, topologia, nível, bits U e X, protocolo de origem, métrica, classe de preferência e geração SPF. Quando uma correção muda a interpretação, esses elementos permitem reproduzir a decisão sem reescrever os bytes que foram recebidos.

Um comprovante útil termina no resultado do pacote

Um comprovante não secreto pode reunir identidade do nó, adjacência e tipo de PDU; identificador de topologia; Protocols Supported e NLPID IPv6; endereço TLV 232 e seu contexto Hello ou LSP; prefixo TLV 236 ou 237, bits, métrica e sub-TLVs; geração SPF; predecessor e próximo salto; todos os membros ECMP; capacidade IPv6 de cada trânsito; escolha do RIB; geração e resultado da programação do FIB; resolução link-local; caminho da sonda; resultado de entrega; e decisão de reversão.

Esse encadeamento preserva uma divisão de responsabilidade. O processo de roteamento tem autoridade para descrever alcance. O sistema de encaminhamento é que precisa mover o pacote. Uma topologia pode estar correta como modelo e ainda não fornecer a prova necessária para afirmar que IPv6 atravessou aquele caminho.

Sources