요약

  • RFC 791의 Type 68 옵션은 IP 모듈이 시각을 기록할 수 있게 하고, 선택적으로 주소도 함께 기록했다. 4비트 오버플로 카운트는 옵션이 가득 차서 기록하지 못한 모듈 수를 담았다.
  • 시계가 서로 다를 수 있고 기록 공간에도 한계가 있었기 때문에, 이 옵션은 신뢰할 수 있는 종단 간 지연 측정이 아니라 선별된 처리 관찰을 기술하는 것이었다.

데이터그램 안의 시계 기록

RFC 791은 인터넷 타임스탬프 옵션을 Type 68로 정의했다. 발신자가 IP 헤더에 공간을 미리 확보해 두면, 패킷을 처리하는 각 IP 모듈이 타임스탬프를 기록할 수 있었다. 값은 자정(UT) 이후 밀리초를 세는 32비트 카운트였다. UT를 사용할 수 없거나 시계가 UT를 기준으로 하지 않는 경우, 최상위 비트가 그 값을 비표준으로 표시했다.

옵션의 플래그는 각 슬롯의 내용을 바꿨다. 플래그 0은 시각만 저장했다. 플래그 1은 각 시각에 주소를 짝지어 저장했다. 플래그 3은 주소를 미리 지정해 두고, 자신의 주소가 다음 목록 항목과 일치하는 모듈만 시각을 기록했다. 포인터는 다음 슬롯을 가리켰다. 길이는 40옥텟을 넘을 수 없었기 때문에, 발신자는 이 패킷 헤더에서 기록에 얼마를 쓸지 선택해야 했다.

이 한계는 옵션에 특별한 종류의 부정적 근거를 부여했다. 4비트 오버플로 필드는 가득 찬 옵션을 만나 타임스탬프를 추가하지 못한 IP 모듈의 수를 셌다. 공간이 더 이상 없으면 모듈은 패킷을 전달하고 카운터를 늘렸다. 그러나 약간의 공간이 남아 있어도 타임스탬프 하나를 담기에 충분하지 않거나, 오버플로 카운트 자체가 표현 범위를 넘어서면 RFC 791은 해당 데이터그램을 오류로 간주하고 ICMP Parameter Problem 보고를 허용했다. 이 필드는 어떤 라우터가 누락되었는지, 왜 누락되었는지 식별해 주지 않는다.

명세는 기록이 이동하는 범위도 제한했다. 이 옵션은 프래그먼트로 복사되지 않으며 한 번만 나타날 수 있었다. 따라서 수신자는 모든 프래그먼트가 완전한 경로 이력을 담고 있다고 가정할 수 없다.

경과 시간이 아니라 관찰 기록

타임스탬프의 나열은 지연 추적처럼 보일 수 있다. 그러나 RFC 791은 시계의 동기화, 시계의 정확성, 모든 라우터의 참여, 완전한 홉 목록을 보장하지 않았다. 타임스탬프는 하나의 IP 모듈이 자기 시계로 기록한 내용을 기술한다. 두 값을 빼면 실제 전송 시간에 시계 오프셋이 섞일 수 있다. 방어 가능한 해석은 더 좁다. 패킷은 주소와 시각의 유한한 관찰 집합과 오버플로 카운트를 함께 담을 수 있다는 것이다.

이후의 호스트 요구사항 명세는 이 기능의 선택적 성격을 재확인했다.RFC 1122는 타임스탬프 옵션의 생성과 처리를 선택 사항으로 규정했다. 즉, 프로토콜 정의가 형식과 동작을 제공했을 뿐, 호스트나 라우터가 이를 배치했다는 사실을 확립하지는 않았다.

2014년RFC 7126은 이 옵션을 시계 정보, 토폴로지 단서, 장치 핑거프린팅의 원천으로 기술했다. 동시에 광범위한 폐기 때문에 이 기법들이 실질적으로 불가능해졌다고 서술하고, 라우터·보안 게이트웨이·방화벽이 이 옵션을 포함한 패킷을 폐기해야 한다(SHOULD)고 권고했다. 이는 보안 권고이자 해당 RFC의 서술이며, 모든 네트워크에 대한 현재 측정 결과가 아니다.

이 옵션의 역사는 관측 가능성에 대한 간결한 교훈이다. 인밴드 기록은 유용한 흔적을 노출하면서도 불완전하고, 시계 의존적이며, 헤더 공간을 많이 소모할 수 있다. 그 형식은 참여 모듈이 무엇을 기록할 수 있었는지를 말할 뿐, 기록의 부재를 어떤 홉도 존재하지 않았다는 증거로 바꾸지 않는다.

출처