Resumo

  • RFC 9565 referencia o registro oficial de TCP Header Flags da IANA e determina que bits de controle, atribuídos ou não, sejam exportados conforme observados.
  • O resultado é um OR sobre os pacotes do Flow: um bit indica ocorrência em algum momento, não ordem, direção, quantidade, coexistência no mesmo pacote ou estado TCP.
  • A interpretação auditável exige largura do campo, Template, época e capacidade do exportador, direção do Flow e evidência adicional quando a conclusão depender de cronologia.

Um coletor recebe apenas um octeto e o banco armazena dezesseis bits. Os oito novos lugares aparecem como zeros impecáveis. A interface não avisa que metade deles nunca foi medida. A normalização produziu uma resposta onde o equipamento havia declarado um limite.

Essa é uma das fronteiras que RFC 9565 torna explícitas ao revisar o Information Element 6 do IPFIX. O elemento continua sendo unsigned16 com semântica de flags, mas suas posições de controle passam a acompanhar o registro TCP Header Flags da IANA. Tanto bits atribuídos quanto ainda não atribuídos devem ser preservados como vistos. Assim, uma extensão futura ou um uso incomum não some só porque a tabela local ficou antiga.

A fidelidade, porém, alcança apenas o que o processo observou.

Uma união não contém uma sequência

Para cada posição, tcpControlBits responde se pelo menos um pacote associado ao Flow apresentou aquele bit. A operação equivale a um OR acumulado. Depois dela, não se sabe qual pacote contribuiu, quantas ocorrências houve, se duas bandeiras estavam juntas nem qual terminal as enviou.

SYN e ACK no mesmo valor não demonstram que o three-way handshake terminou. FIN e RST não estabelecem qual veio primeiro ou quem encerrou a comunicação. O Flow depende de chaves, Observation Point, direção e temporizadores do sistema de medição. A máquina de estados TCP permanece nos terminais. O registro agregado pode selecionar tráfego para investigação; não pode assumir a autoridade dos terminais.

A largura declara o alcance da prova

O Template IPFIX informa quais elementos compõem o Data Record e qual é o comprimento de cada um. Na codificação de tamanho reduzido, um tcpControlBits de um octeto cobre somente as posições 8 a 15. Ele não afirma nada sobre 4 a 7. Um Metering Process sem capacidade para a largura inteira deve usar essa forma honesta.

Guardar apenas um inteiro expandido destrói a distinção entre “ausente” e “fora do campo observado”. É preciso manter o Template, sua identidade e sequência, o Observation Domain, a versão do exportador e o intervalo em que essa combinação esteve ativa.

As posições 0 a 3 pertencem à região Data Offset do cabeçalho TCP. Em tcpControlBits, devem ser zeradas ou ignoradas; o comprimento de cabeçalho cabe a tcpHeaderLength. Tratar as dezesseis posições como bandeiras equivalentes é atribuir significado onde não existe.

Registro e equipamentos vivem em velocidades diferentes

RFC 9293 consolida as bandeiras conhecidas. RFC 8311 alterou o tratamento de uma posição antes associada ao uso experimental NS. Definições anteriores ligadas à RFC 7125 mandavam zerar posições que a revisão atual procura conservar. Por isso, um zero histórico pode significar ausência real, regra antiga, largura reduzida ou lacuna de observação.

O inverso também ocorre: um coletor antigo pode chamar de reservado um bit já reconhecido pelo registro atual. O valor observado deve sobreviver ao rótulo local para que possa ser reinterpretado. A cadeia correta junta pacote, exportador, Template, registro e tempo.

Na separação de camadas de Heng Lu, a IANA exerce autoridade simbólica; a RFC define o contrato; o código em execução realiza a medição; os terminais mantêm o estado da conexão. O bitmap é um recibo comprimido entre essas camadas, não um substituto para elas.