요약

  • RFC 9870은 플로우 내에서 특정 SAFE 또는 UNSAFE UDP 옵션 종류가 적어도 한 번 관측됐는지를 기록하는 IPFIX 정보 요소를 등록한다.
  • 설정된 비트는 존재에 대한 접수 증표다. 패킷 순서, 빈도, 옵션 값, 처리 성공 여부, 애플리케이션 전달 또는 운영상 채택 여부를 드러내지 않는다.

비트맵은 그것이 뒷받침할 수 있는 것보다 큰 결론을 부추긴다. 설정된 하나의 비트는 깔끔한 답처럼 보인다. 이 옵션이 있었다는 것. 그 답은 실재하지만, RFC 9870은 운영자가 다음으로 물어보기 쉬운 질문들 앞에서 일부러 멈춘다. 어떤 데이터그램이 옵션을 실었는지, 몇 번 나타났는지, 어떤 값을 담았는지, 수신자가 이를 반영했는지, 애플리케이션이 이점을 얻었는지는 말하지 않는다.

구분은 내보내는 대상에서 시작된다. UDP 옵션은 UDP 패킷 뒤에 이어지는 잉여 영역을 차지하며 한 바이트짜리 Kind 값을 사용한다. RFC 9870은 이러한 옵션을 재정의하거나 운영 지침을 제공하지 않는다. IPFIX 익스포터가 관측한 내용을 보고할 수 있는 정보 요소를 정의한다.

두 개의 비트 필드가 두 개의 레지스트리를 보존한다

사양은 옵션 공간을 분리한다. Kind 0부터 191까지는 SAFE이고, 192부터 255까지는 UNSAFE다.udpSafeOptions(정보 요소 525)는 SAFE 종류를 위한 부호 없는 256비트 필드를 제공하며, 상위 64비트는 0으로 유지해야 한다.udpUnsafeOptions(정보 요소 526)는 UNSAFE 종류를 위한 부호 없는 64비트 필드를 제공한다.

어느 필드에서든 비트가 설정되면 해당 옵션 종류가 익스포터가 관측한 플로우 내에 적어도 한 번 나타났다는 뜻이다. 이는 개별 패킷의 재구성이 아니라 관측 경계를 가로지르는 집계다. 따라서 한 플로우는 단 한 번 옵션을 실었고 다른 플로우는 서로 다른 위치와 값으로 반복 실었더라도, 두 플로우는 같은 비트맵을 만들 수 있다.

이 분리는 축소 인코딩에도 도움이 된다. 고번호 비트가 불필요하면 IPFIX는 더 짧은 표현을 실을 수 있다. RFC 9870의 예제는 필수 SAFE 옵션이 한 옥텟에 들어가는 것을 보여준다. 압축은 전송되는 옥텟 수를 바꿀 뿐 근거의 의미를 바꾸지 않는다. 생략된 상위 영역은 엔드포인트가 무엇을 처리했는지에 대한 서사가 아니다.

실험용 식별자에는 별도의 근거가 필요하다

일반적인 실험 비트는 서로 다른 실험을 구분할 수 없다. 그래서 정보 요소 527부터 529까지는 16비트 실험 식별자와 관측된 SAFE 또는 UNSAFE 실험 식별자 목록을 담는다. 해당 목록이 존재하면 EXP 또는 UEXP 비트맵 플래그보다 우선하며, 익스포터는 그 플로우에 대해 일반 플래그를 설정하지 않아야 한다.

이 우선 규칙은 호환되지 않는 두 표현이 독립적인 교차 확인인 것처럼 보이는 것을 막는다. 목록은 어떤 실험 번호가 목격됐는지 식별할 수 있다. 그래도 옵션이 수용됐는지, 올바르게 실행됐는지, 성공적인 애플리케이션 교환과 연관됐는지는 증명하지 않는다.

유용한 주장은 경계가 있는 주장이다

IPFIX 수집기는 이러한 요소를 사용해 어떤 옵션 종류가 어디서 관측됐는지 찾고, 관측 지점을 비교하고, 더 면밀한 검사가 필요한 플로우를 식별할 수 있다. 그러나 이를 패킷 캡처로 바꿀 수는 없다. 운영상 결론이 순서, 빈도, 내용 또는 엔드포인트 동작에 의존한다면, 그 결론에는 이러한 사실을 기록하는 근거가 필요하다.

기본 사양은RFC 9870이다. UDP 옵션의 배경은RFC 9868에서 온다. IPFIX 프로토콜과 정보 모델은RFC 7011과RFC 7012에서 정의된다. 현재 등록 상태는IANA IPFIX 정보 요소 레지스트리에서 확인할 수 있다. 출판과 등록은 형식을 확립할 뿐, 현재의 배포나 성능을 확립하지 않는다.