요약

  • RFC 1241은 수정되지 않은 “Clear Datagram”을 외부 IP 헤더와 8옥텟 프로토콜 헤더 안에 넣고, 별도의 Encapsulation Space를 통해 라우팅했습니다.
  • 32비트 Flow ID는 글로벌이 아닌 로컬 식별자였으며, 포워딩과 오류 반환을 가능하게 하는 매핑은 프로토콜이 아니라 상위 계층이 생성·유지해야 했습니다.
  • 터널 내부에서 발생한 ICMP 오류는 외부 헤더와 캡슐화 헤더 전체를 인용했지만 Clear Datagram은 전혀 포함하지 않았습니다. 따라서 외부 장애 증거는 원인이 되는 원래 패킷을 잃을 수 있었습니다.

투명성은 진실이 살아야 하는 두 번째 장소를 만들었다

1991년 7월에 발표된RFC 1241은 실험적 인터넷 캡슐화 프로토콜을 제안했습니다. Robert Woodburn과 David Mills는 문서의 두 세계에 의도적인 이름을 붙였습니다. 캡슐화 이전의 패킷은Clear Datagram이며,User Space에 존재합니다. 외부 주소와 라우팅은Encapsulation Space에 속합니다. 캡슐화 장치는 클리어 패킷을 두 번째 공간으로 매핑하고, 역캡슐화 장치는 껍데기를 벗겨 원래 패킷을 일반 IP 포워딩으로 되돌립니다.

동기는 실용적인 것이었습니다. 캡슐화는 라우팅 장애, 고장 난 게이트웨이 또는 도메인 전체를 우회할 수 있었습니다. 또한 모든 발신 호스트가 새로운 토폴로지를 배우지 않아도 되는 라우팅 로직 실험을 지원할 수 있었습니다. 소스 라우팅과 달리 발신자가 중간 경로를 직접 지정할 필요가 없었고, IP 설계를 교체하는 방식과 달리 이미 설치된 IP 네트워크 안에서 동작할 수 있었습니다.

이것이 의도된 투명성이었습니다. 발신 측은 터널에 대해 아무것도 알 수 없었습니다. 그러나 발신 측의 무지는 지식이 다른 곳으로 이동해야 함을 의미했습니다. 캡슐화 장치는 어떤 클리어 패킷이 어떤 터널로 들어가는지 결정해야 했습니다. 역캡슐화 장치는 다음 목적지를 알아야 했습니다. 하나의 플로우가 여러 캡슐화/역캡슐화 쌍을 거친다면, 모든 쌍이 동일한 논리 경로를 유지할 만큼 충분한 로컬 상태를 가져야 했습니다.

RFC 1241은 이 경로를Flow라고 불렀습니다. Flow ID는 32비트였지만 하나의 캡슐화 장치 또는 역캡슐화 장치 내에서만 유일했습니다. 글로벌 식별자가 아니라는 점이 명시되어 있었습니다. 같은 Flow가 다음 홉에서는 다른 번호를 가질 수 있었습니다. 따라서 오류를 반환하려면 이전 캡슐화 장치의 주소와 로컬 Flow ID가 필요했고, 거꾸로 한 단계 올라갈 때마다 또다른 변환이 필요했습니다.

프로토콜은 이러한 테이블이 어떻게 구축되고 최신 상태로 유지되는지 정의하지 않았습니다. 상위 계층 개체가 이를 소유했으며, 실험 환경에서는 ASCII 파일로도 충분하다는 언급까지 있었습니다. 결과적으로 조회 성공은 좁은 사실만 증명했습니다. 이 노드가 그 순간 일치하는 로컬 항목을 가지고 있었다는 것뿐입니다. 그 항목이 최신인지, 다음 노드가 의도된 매핑을 사용하는지, 오류에 필요한 역방향 체인이 여전히 존재하는지는 증명하지 못했습니다.

꼭 필요한 숨김용 껍데기가 숨기려던 패킷 자체를 바꾸었다

캡슐화 헤더는 새로운 외부 IP 헤더와 8옥텟 프로토콜 헤더로 구성되었습니다. 후자는 버전, 메시지 유형, 원인 코드, 체크섬, Flow ID를 담았습니다. Clear Datagram은 그 뒤에 변경 없이 이어졌습니다. 그러나 “변경 없이”는 내부 바이트를 가리킬 뿐, 네트워크가 패킷을 다루는 방식을 가리키는 것은 아니었습니다.

외부 헤더를 구성할 때 내부 IP 헤더의 대부분 필드는 무시되었습니다. 외부 발신·수신 주소는 캡슐화 장치와 역캡슐화 장치가 되었습니다. 우선순위와 서비스 품질 비트는 복사되었으나, 타임스탬프·record-route·source-route 옵션은 그렇지 않았습니다. 내부 TTL은 복사되지 않았으며, 캡슐화 전에 일반 포워딩이 TTL을 감소시켜야 했고, 일반 IP 포워딩을 우회하는 역캡슐화 장치도 다음 Flow로 패킷을 보내기 전에 그 의무를 떠안아야 했습니다.

단편화는 더 깊은 비용을 드러냈습니다. 새 헤더는 외부 데이터그램을 더 크게 만들었습니다. 발신 인터페이스의 MTU에 맞던 클리어 패킷이 캡슐화 후 너무 커질 수 있었습니다. RFC 1241은 외부 IP 단편화를 허용했지만 단편화가 비효율적이라고 지적했습니다. 캡슐화 장치가 이를 금지하면 캡슐화 경로의 실효 MTU가 작아지고 발신 측에는 의미 있는 ICMP 응답이 필요해졌습니다.

분류 역시 무너질 수 있었습니다. 매핑 테이블은 TCP 포트를 검사하거나 심지어 연결을 구분하도록 허용되었습니다. User Space 게이트웨이가 이미 IP 데이터그램을 단편화했다면 첫 번째 단편만 TCP 헤더를 담습니다. 포트 기반 규칙은 첫 단편에 일치할 수 있지만 나머지 단편은 IP 필드만 노출합니다. 문서는 측정된 실패 사례를 주장하지 않았습니다. 완전한 헤더에서는 정확해 보이는 분류 규칙이 패킷의 단편들에 걸쳐서는 더 이상 정확하지 않게 되는 이유를 지적한 것입니다.

한 해 전에 발표된RFC 1191은 Path MTU Discovery를 위한 피드백 루프를 명시했습니다. Don't Fragment 비트를 설정하고, “fragmentation needed” ICMP 메시지를 받은 뒤, 가정된 경로 MTU를 낮추는 방식입니다. RFC 1241은 이 루프를 껍데기 너머로 단순히 복사할 수 없었습니다. 외부 패킷의 발신자는 캡슐화 장치이므로 네트워크가 당연히 그곳으로 오류를 반환했습니다.

ICMP는 편지봉투는 돌려보내고 편지 내용은 버렸다

결정적인 대목은 RFC 1241의 ICMP 부록에 나옵니다.RFC 792에 따르면 ICMP 오류는 문제의 IP 헤더와 그 뒤 최소 64비트의 데이터를 담습니다. RFC 1241의 경우 그 64비트가 정확히 8옥텟 Encapsulation Protocol Header였습니다. 인용은 Clear Datagram이 시작되기 전에 끊겼습니다.

캡슐화 장치는 어떤 외부 목적지와 어떤 로컬 Flow가 문제를 겪었는지 볼 수 있었습니다. 그러나 원래의 내부 IP 헤더, 원래 발신 주소, 실패한 패킷의 TCP 헤더는 볼 수 없었습니다. Flow ID만으로 정확한 Clear Header를 재구성하는 것은 불가능했습니다. 서로 다른 여러 헤더가 같은 Flow로 매핑될 수 있기 때문입니다. 패킷은 발신 측에게 터널을 숨김으로써 순방향에서 투명했습니다. 그 결과 생긴 오류는 역방향에서 불투명했습니다. 터널이 진단용 인용에서 발신 패킷 자체를 숨겨버린 것입니다.

RFC 1241은 내장된 두 오류 경로를 구분했습니다. 알 수 없는 Flow ID는 이전 캡슐화 장치와 상위 계층 테이블 관리자에게 보고될 수 있었습니다. 다른 ICMP 메시지는 감싸져 Flow를 따라 역방향으로 운반될 수 있었고, Flow ID는 매 홉에서 변환되었습니다. 그러나 ICMP 개체를 역방향으로 옮긴다고 누락된 내부 바이트가 재생성되지는 않았습니다. 그리고 오류를 보내던 중 오류가 발생하면 프로토콜은 더 이상 오류를 생성하지 않았습니다.

문서는 절충안도 검토했습니다. ICMP 이벤트가 Flow에 표시를 남기고, 다음으로 일치하는 클리어 패킷이 캡슐화 장치가 발신 측을 향해 새 오류를 생성하게 하는 방식이었습니다. 이는 다음 패킷이 이전 패킷의 상태를 조사하는 탐침이 되는 것입니다. 일대일 귀속은 아니었고, RFC 1241은 이 접근이 일부 메시지 클래스에만 아마도 안전하다고 판단했습니다. 이후의 알림은 현재 Flow 상태를 기술할 수 있지만, 이전 실패에 대한 바이트 단위 영수증으로 쓰일 수 없었습니다.

이후의 터널 문서들은 관측성 문제를 계속 드러냈다

이후의 RFC들을 RFC 1241이 널리 배치되었다는 증거나 단순한 직선적 계승으로 읽어서는 안 됩니다. 다만 이 RFC가 기술한 경계가 구조적으로 남았다는 것을 보여줍니다.RFC 1853은 1995년 IP-in-IP 실무를 문서화하며, 특별한 접착 헤더가 없다는 점에서 RFC 1241과 구별했고, 자신의 구성과 일부 문구가 이전 문서에서 파생되었음을 인정했습니다.

1996년의 IP 내 IP 캡슐화 표준 트랙 문서인RFC 2003은 동일한 진단 제약을 명시했습니다. 인용된 8옥텟만으로는 내부 IP 헤더까지 담기에 부족하다는 것입니다. 그 답에는 MTU, TTL, 도달 가능성을 위한 터널 소프트 상태가 포함되어, 이후 패킷들을 캡슐화 장치가 학습한 내용과 대조할 수 있게 했습니다. 그 상태는 많은 경우 더 나은 오류 생성을 가능하게 했지만, 여전히 모든 외부 오류를 내부 패킷의 일대일 기록으로 바꾸지는 못했습니다.

RFC 4459는 이후 네트워크 내 터널링에서 패킷 크기 처리를 흔하고 결코 사소하지 않은 문제로 기술했습니다. 외부에서 단편화하거나, 더 낮은 MTU를 통보하거나, 여유 용량을 보장하거나, 내부 패킷을 단편화하는 것—각 선택은 비용과 증거를 서로 다른 곳으로 옮깁니다. 오래 지속되는 교훈은 어떤 터널 형식이 이겼다는 것이 아니라, 투명한 계층을 추가하면 크기·신원·실패 해석에 대한 새로운 권한이 생긴다는 것입니다.

증명 가능한 것은 추론 가능한 것보다 작아야 한다

RFC 1241에서 관찰자는 제안된 껍데기의 형식, Flow ID의 로컬 범위, 필요한 역방향 변환, 일반 ICMP 인용에서 Clear Datagram이 사라진다는 사실을 증명할 수 있습니다. 이 문서는 특정 구현이 이 프로토콜을 사용했다는 것, 터널이 실제 트래픽을 운반했다는 것, 내부 패킷이 도착했다는 것, 원래 발신자가 동등한 오류를 받았다는 것을 증명할 수 없습니다.

운영 기록은 두 세계를 모두 보존해야 합니다. 터널 입구의 패킷 캡처는 Clear Header를 외부 헤더 및 로컬 Flow ID와 결합할 수 있습니다. 출구의 캡처는 역캡슐화를 보여줄 수 있습니다. 버전 관리된 테이블 스냅샷은 노드가 Flow를 어떻게 변환하려 했는지 보여줍니다. ICMP 캡처는 정확히 인용된 바이트를 보여줍니다. 내부 패킷의 결과에 대한 주장은 상관된 체인만이 뒷받침할 수 있으며, 없는 고리는 “터널”이라는 단어로 채워지지 않고 그대로 없어야 합니다.

RFC 1241의 역사적 중요성은 바로 이 절제에 있습니다. 가상 라우팅 표면을 제안한 뒤, 그 표면이 어디에서 투명성을 잃는지 문서화했습니다. 터널은 패킷을 운반할 수 있었습니다. 오류는 Flow를 운반할 수 있었습니다. 그러나 어느 쪽도 홀로 원래의 질문을 집으로 데려갈 수는 없었습니다.

출처