Resumo

  • tcpActiveOpens e a maioria dos objetos TCP continuaram aplicáveis a conexões IPv4 e IPv6; RFC 2452 não criou duas cópias dos mesmos contadores.
  • Na tabela de conexões IPv6, ipv6TcpConnIfIndex tornou-se a quinta chave porque os quatro valores de endereço e porta nem sempre distinguiam uma linha em um nó com várias interfaces.

Quando os mesmos quatro campos não identificam a mesma linha

Uma interface pode mostrar um endereço IPv6 local ao enlace, enquanto outra interface do mesmo nó usa o mesmo valor em outro contexto. Se a tabela guardar somente endereço local, porta local, endereço remoto e porta remota, duas observações podem parecer idênticas. A ambiguidade não está necessariamente na conexão TCP em si; está na chave que o plano de gerenciamento usa para localizar uma linha.

RFC 2452, publicado em dezembro de 1998, acrescentou ipv6TcpConnIfIndex depois dos quatro campos familiares. O índice da linha passou a ter cinco componentes. Isso não introduziu uma quinta coordenada no cabeçalho TCP, nem mudou a tupla de transporte usada na rede. A quinta informação completava a identidade da observação dentro da MIB, onde o endereço IPv6 isolado podia não ser único no nó.

Contar o mesmo evento sem inventar duas métricas

A outra decisão do documento foi não separar a maioria dos objetos TCP por família de IP. RFC 2452 afirma que a versão IP é quase invisível para o TCP: uma implementação precisa entender os endereços IPv6, não ganhar um novo “TCPng”. tcpActiveOpens, por exemplo, conta as transições diretas de CLOSED para SYN-SENT, independentemente de IPv4 ou IPv6 levar a conexão.

Essa métrica compartilhada preserva o significado do evento, mas não responde a perguntas que ela nunca foi desenhada para responder. Um único valor não atribui o incremento a uma família IP, conexão, interface, processo ou pessoa. Também não demonstra que toda implementação guardou contadores em um único espaço interno. O RFC define o contrato da informação gerenciada, não a arquitetura de cada produto.

A exceção era a tabela. RFC 2012 usava o tipo SMIv2 IpAddress, com quatro octetos, incapaz de representar um endereço IPv6. RFC 2452 então criou ipv6TcpConnTable, somente para conexões entre dois endpoints IPv6, enquanto as conexões IPv4 continuaram em tcpConnTable. Uma tabela nova para as duas famílias exigiria mudanças no RFC 2012 e poderia quebrar o caminho de implementações apenas IPv4. A tabela paralela foi uma ponte de compatibilidade; o módulo ficou sob o ramo experimental porque se esperava que uma futura atualização incorporasse seus objetos.

O índice expressa escopo, não uma entidade

O significado da interface dependia da combinação de endereços. Quando o endereço remoto era link-local e o local não, o índice identificava uma interface no mesmo enlace que o remoto. Nos demais casos, apontava para a interface associada ao endereço local. Um número diferente de zero correspondia à interface de mesmo índice em ipv6IfIndex e precisava permanecer constante durante a vida da conexão.

Quando não era possível determinar a interface, o valor podia ser zero; ::0 como endereço local abrangente aparece como um possível caso. Zero não nomeia uma interface oculta: mantém explícita a ausência de conhecimento. Preencher essa lacuna com uma interface provável depois do fato converte a incerteza em uma atribuição que o RFC não fez.

A linha também era transitória. Ela desaparecia quando a conexão chegava a CLOSED ou logo depois. Portanto, a tabela mostrava uma observação de uma conexão atual; não fornecia identidade duradoura de servidor, usuário, processo ou serviço. Endereços e interface tampouco provam propriedade, alcance, identidade do par ou sucesso da aplicação.

O estado gravável deleteTCB(12) foi herdado pela tabela IPv6 e podia encerrar a conexão no nó gerenciado. O artigo já publicado sobre RFC 2012 é dono dessa história de intervenção; aqui, o recurso só delimita a sensibilidade da superfície. Uma chave precisa não concede autoridade para agir e não prova o que o outro endpoint recebeu.

Em 2005, RFC 4022 substituiu RFC 2012 e RFC 2452 por um TCP-MIB independente da versão IP. Usou convenções genéricas de endereço, sem preservar intactos a tabela IPv6 e seu quinto índice. RFC 4001 forneceu InetAddressType e InetAddress, incluindo formas com zona; RFC 4007 descreveu os conceitos de escopo e zona IPv6. Em 2017, RFC 8096 deu outro passo: reclassificou RFC 2452 como Historic e marcou os antigos módulos IPv6 como obsoletos para manutenção de repositórios MIB. A convergência técnica e a reclassificação histórica são eventos separados.

Fontes