요약

  • RFC 1393은 IPv4 옵션 82와 이에 대응하는 ICMP 메시지를 정의하여, 단 하나의 패킷이 참여하는 각 라우터가 자신의 홉, 출력 링크 속도 및 MTU를 보고하도록 만들 수 있게 했습니다.
  • 이 실험은 모든 홉에서 새로운 패킷별 동작을 요구하는 조건에서만 반복 프로브를 줄일 수 있었고, 널리 배포되지 못한 채 Historic으로 격하되었으며 현재는 필터링이 권장됩니다.

경로가 직접 쓴 트레이스

익숙한 traceroute 알고리즘이 성공하는 이유는 라우터가 이미 만료된 Time to Live를 보고하는 방법을 알고 있기 때문입니다. 발신자는 TTL 1, 그다음 2, 그다음 3으로 패킷을 전송하며, 목적지에 도달할 때까지 ICMP Time Exceeded 메시지를 수집합니다. RFC 1393은 홉당 대략 두 개의 패킷이 소요된다고 계산하면서 두 가지 한계를 지적했습니다. 연속적인 프로브가 변하는 경로를 만날 수 있다는 점, 그리고 이 방법은 되돌아가는 경로는 측정할 수 없다는 점입니다.

RFC 1393이 제안한 대안은 발신 패킷에 Traceroute 옵션을 담는 것이었습니다. 옵션 유형 82는 복사 비트 0, 디버깅 및 측정 클래스 2, 옵션 번호 18을 인코딩했습니다. 이 옵션은 발신자가 선택한 식별자, 발신 홉 카운트, 복귀 홉 카운트, 그리고 발신자의 IPv4 주소를 담았습니다. 이 식별자는 IPv4 헤더의 Identification 필드와 명시적으로 무관했습니다.

발신자는 발신 카운트를 0으로, 복귀 카운트를0xFFFF로 설정합니다. 이는 발신 방향을 뜻하는 센티널 값입니다. 각 포워딩 라우터는 기록된 발신자에게 새로운 ICMP Traceroute 메시지를 보내고, 해당 카운터를 증가시키며, 출력 링크의 속도와 MTU를 보고하도록 기대되었습니다. 알 수 없는 경우에는 둘 다 0으로 보고합니다. 옵션이 표시된 패킷 자체는 옵션이 없을 때와 동일한 경로를 따랐습니다.

목적지에서는 ICMP Echo Reply와 같은 응답이 옵션을 유지하고, 식별자·발신자·발신 카운트를 복사한 뒤 복귀 카운트를 0에서 시작할 수 있었습니다. 돌아오는 길의 라우터들도 그 방향에 대해 보고할 수 있었습니다. 주장된 경제성은 2n 대신 n+1개의 패킷이라는 점, 그리고 일반 프로빙으로는 직접 얻을 수 없는 경로 비대칭에 대한 시각이라는 것이었습니다.

그러나 이 카운터들은 TTL이 아니었습니다. 라우터가 실제로 Traceroute 보고서를 보낼 때만 증가했습니다. 따라서 보고서가 하나 빠지면 신뢰할 수 있는 더 짧은 경로가 아니라 구멍이 생기며, 수신한 메시지를 단순히 세는 것만으로는 경로 길이를 확정할 수 없습니다.

성사되지 않은 배포 협상

이 설계가 끝점에서 얻는 경제성은 라우터 내부의 새로운 작업에 의존했습니다. RFC 1393은 참여하는 모든 라우터가 traceroute 기능을 갖추어야 함을 인정했고, 보안 문제는 논하지 않았습니다. 이 두 가지 사실은 나중에 맞닿았습니다. RFC 7126은 각 라우터에 특수 처리와 ICMP 생성을 강제하는 것이 CPU 자원을 고갈시키는 데 악용될 수 있음을 관찰했습니다.

역사적 결론은 RFC 6814가 내렸습니다. 이 옵션은 Experimental 상태로 남았고 공용 인터넷에서 널리 배포된 적이 없으며, RFC 1393은 2012년에 공식적으로 Historic으로 지정되었습니다. 이어서 RFC 7126은 유형 82를 차단하는 데 따른 운영상 또는 상호운용성 영향이 없음을 기록하고, 라우터·보안 게이트웨이·방화벽이 이를 포함한 패킷을 폐기할 것을 권고했습니다.

이것은 진단 도구가 더 이상 중요하지 않게 된 이야기가 아닙니다. 진단 작업을 어디에 두느냐의 이야기입니다. 기존 traceroute는 라우터가 포워딩 정확성을 위해 이미 갖추고 있던 동작 위에 세워졌습니다. 옵션 82는 전체 경로에 새로운 보고 서비스의 구현을 요구했습니다. 발신자 쪽 프로브 수가 줄어든다고 해서, 홉마다 성공해야만 하는 배포 의존성을 보완할 수는 없었습니다.

출처