요약

  • RFC 1475는 다음 라우터에게만 의미가 있고, 발행한 라우터 밖에서는 불투명하며, 보통 매 홉마다 교체되는 64비트 순방향 경로 식별자를 제안했다.
  • 0 또는 무효한 식별자는 라우터를 일반 목적지 조회로 되돌렸고, 집계, 경로 변경, 플로우 상태, 프로토콜 변환은 모두 새로운 해석을 강제할 수 있었다.
  • 실험적 RFC로의 출판, 이후 CATNIP 계보 참여, 최종 Historic 지위는 문서와 결정을 서술할 뿐, 관찰된 구현이나 패킷 여정을 말해주지 않는다.

유혹적인 오독

1993년 6월,RFC 1475는 TP/IX, 즉 인터넷 프로토콜 버전 7이라고도 불리는 제안을 내놓았다. 이 제안은 주소를 확대하고 전송 필드를 바꾸며, 홉별 데이터그램 포워딩과 더 빠른 경로·플로우 메커니즘을 결합하려 했다. 한 필드가 그 야망을 구체화했다. 모든 데이터그램에 64비트 순방향 경로 식별자가 담기는 것이었다.

이 이름은 쉬운 오해를 불러온다. 경로 식별자가 패킷 안에 있다면, 어쩌면 패킷이 자신의 경로를 아는 것일지도 모른다. 어쩌면 어느 한 지점의 캡처가 선택된 경로를 드러내는 것일지도 모른다. 어쩌면 반복되는 값이 두 패킷이 같은 길을 따랐음을 보여주는 것일지도 모른다.

RFC의 절차는 이 세 가지 지름길을 모두 부정한다. 그 값은 완전한 길을 서술하지 않았다. 그것은 한 라우터의 사적 라우팅 상태에서 만들어져, 그 라우터로 트래픽을 보내는 이웃이 사용하도록 지정된 핸들이었다. 그 의미는 다음에 이를 받을 기계에만 국한되었다. 상류 시스템은 그 핸들의 해석을 소유하지 않은 채 운반만 했다.

이것은 용어 뒤에 숨겨진 결함이 아니었다. 그것이 곧 메커니즘이었다.

세 라우터, 세 가지 의미

RFC 1475는 호스트 X와 Y 사이에 라우터 A, B, C를 두고 이 설계를 설명한다. C가 Y를 향한 경로를 B에 알리면서 C 내부적인 식별자를 함께 포함한다. 이 문서는 그 식별자가 테이블 인덱스, 심지어 실제 메모리 주소일 수도 있다고 허용한다. B는 C의 값을 불투명한 객체로 취급한다. B는 다시 C를 거치는 자신의 경로를 만들고, B 내부적인 서로 다른 식별자를 A에 알린다.

X가 첫 데이터그램을 보내면 경로 정보가 없으므로 필드에 0을 넣는다. A는 일반 목적지 조회를 수행하고, B를 거치는 경로를 찾아 B의 사적 식별자를 데이터그램에 적어 전달한다. B는 직접 해석할 수 있는 값을 받아 C를 거치는 경로를 찾고, 필드를 C의 식별자로 교체한 뒤 패킷을 보낸다. C는 자신의 식별자를 소비하고 필드를 지운 뒤 Y로 전달한다. Y는 자신의 목적지 주소를 인식하고 경로 식별자는 무시한다.

필드 이름은 그대로인 채 그 권위가 매 홉마다 바뀐다. A의 송신 지점에서는 B가 이전에 A에게 말했던 내용에 대한 증거다. B의 수신 지점에서는 B의 상태에 대한 사용 가능한 키일 수 있다. B의 송신 지점에서는 C에 속한 무언가로 덮어써졌다. 목적지에서는 어떤 필수적인 의미도 갖지 않는다.

64비트만 기록한 패킷 캡처는 그 사적 테이블들을 재구성할 수 없다. 그 값을 '경로'라고 부르는 로그는 발행 라우터, 유효 구간, 목적지 검사, 이어지는 재기록을 지워버린다. 같은 숫자 값이 두 라우터에서 서로 무관한 의미를 가질 수 있고, 서로 다른 두 값이 같은 물리 링크를 따라 데이터그램을 진행시킬 수도 있다. 비트열은 실재한다. 전역적 해석은 그렇지 않다.

0은 결정 요청이었다

0은 '경로가 존재하지 않음'을 뜻하지 않았다. 그것은 현재 라우터가 데이터그램 안에서 사용 가능한 빌린 식별자를 갖지 못했으므로 일반적인 경로 탐색을 써야 함을 뜻했다. A는 자기 테이블에서 목적지를 찾고 다음 지역 인계를 시드했다.

무효한 식별자도 마찬가지로 소박한 결과를 낳았다. RFC 1475는 라우터가 수신 값을 검증하되, 특히 메모리 주소처럼 보이는 경우에는 반드시 검증하고, 참조된 경로가 데이터그램의 목적지를 서술하는지도 확인하리라고 기대했다. 검증이 실패하면 라우터는 식별자를 조용히 무시하고 0의 경우처럼 행동했다.

이 폴백은 성능과 정확성을 분리한다. 식별자는 조회를 가속할 수 있었지만, 목적지 주소와 로컬 라우팅 테이블이 여전히 복구 권위였다. 토큰 적중만으로는 부족했다. 라우터는 여전히 허용 가능한 범위, 정렬, 객체 유형, 목적지 일관성, 현재 경로 상태를 통제했다.

또한 부재와 실패를 분리한다. 0은 발신이나 변환 시점에 정상일 수 있다. 오래된 값은 목적지에 도달 불가를 선언하지 않고도 거부될 수 있다. 라우터가 다음에 무엇을 했는지는 오직 이후의 조회와 포워딩 결과만이 확립할 수 있다.

집계는 고정 경로라는 환상을 깨뜨렸다

경로 집계는 범위 경계를 피할 수 없게 만들었다. 수신 식별자는 집계 경로만 가리킬 수 있었다. 구성 경로가 갈라지는 라우터에서는 여전히 특정 경로를 선택하고 그에 해당하는 하류 식별자를 데이터그램에 넣어야 했다. 빠른 경로는 빌린 지식이 너무 거칠어지는 지점에서 정확히 끝났다.

경로 변경은 또 하나의 결정을 요구했다. RFC 1475는 데이터그램이 전송 중인 동안 경로가 바뀌면 어느 라우터는 각 데이터그램을 어떻게 '재궤도(re-rail)'할지 결정해야 한다고 말했다. 따라서 패킷이 가진 값은 경로를 고정하지 않았다. 그것은 자신을 만든 전제를 로컬 테이블이 무효화할 수 있는, 움직이는 시스템 안에 도착했다.

이것이 핵심 역사적 교훈이다. 이 제안은 라우팅 상태를 패킷에 더 가까이 두면서도 그 상태가 라우팅에서 벗어났다고 가장하지 않았다. 필드는 인접 라우터 사이에서 지식을 보존할 수 있었다. 그러나 변화하는 결정들의 분산된 수열을 하나의 내구성 있는 종단 간 사실로 바꿀 수는 없었다.

플로우도 같은 경계를 사용했다

TP/IX는 플로우 식별자가 경로 식별자를 대체하는 것도 허용했다. 각 라우터는 플로우가 구축된 경로를 가리키는 사적 플로우 객체를 유지할 수 있었다. 데이터그램은 플로우에 들어가거나 나올 수 있었고, 호스트나 근처 협력 라우터가 삽입할 수 있었다.

여기서도 필드는 송신자에게는 불투명했고 암묵적으로 다음 홉에만 의미를 가졌다. RFC는 라우터가 자신의 경로 ID와 플로우 ID를 사적 방법으로 구분하도록 남겨두었다. 프로토콜은 그 내부 분류를 전역적으로 노출할 필요가 없었다.

따라서 0이 아닌 값의 존재만으로 예약된 플로우가 존재한다고 증명되지 않았다. 관찰자는 발행 라우터의 상태, 값 유형, 생성 시점, 연관 경로, 사용 시각, 포워딩 결과가 필요했다. 그런 다음에도 예약, 용량, 서비스 결과는 별도의 증거를 요구했다.

동반 라우팅 프로토콜은 시간 한정된 주장을 제공했다

RFC 1476은 동반 경로 배포 제안인 RAP을 서술했다. 그 Add Route 명령은 발표 시점에 송신자의 포워딩 데이터베이스에 실제로 적재된 경로를 제시해야 했다. 수신 피어는 그 제시된 64비트 식별자를 그 피어를 향해 되돌아가는 데이터그램에 넣었다.

이 규칙은 떠도는 약속보다 강했지만, 여전히 시간 한정적이었다. '제시 시점에 적재됨'이 영구히 적재됨을 뜻하지는 않았다. 따라서 RAP은 Purge Route에서도 같은 식별자를 사용했다. 퍼지는 수신자에게 경로를 삭제하고 그 경로가 전파된 피어들로부터 폐기하도록 요구했다. 문서는 로컬 삭제 전에 퍼지를 먼저 보내기를 선호했으나, 그 순서가 필수가 될 수는 없음을 인정했다.

삭제, 퍼지 전송, 전파, 전송 중 데이터그램 사이에 여러 시계가 존재했다. 식별자는 이전 제안의 기록으로서는 완벽히 진실할 수 있으면서도 현재 포워딩 상태에는 무용할 수 있었다. 발표, 토큰, 검증, 퍼지, 송신의 증거는 분리된 채 유지되어야 했다.

변환은 관할 경계를 드러냈다

TP/IX는 IPv4와 IPv7 시스템이 임의의 순서로 업그레이드될 수 있게 하려 했다. 그 야망은 변환 지점을 도입했다. 제안의 'Don't Convert' 옵션은 IPv7에서 IPv4로 변환하는 라우터를 제약했지만, 동시에 단단한 경계도 인정했다. 프로토콜은 회선 위의 비트를 지정할 수 있지만, 수신 호스트는 자신의 절차의 일부로 내부적으로 변환할 수 있다는 것이다.

변환 절은 더 많은 한계를 기록했다. 서로 다른 경로를 거쳐 서로 다른 변환 지점에 도달한 조각들은 손실될 수 있었다. 이웃의 역량은 IPv7 데이터그램 수신, 에코 교환 또는 명시적 설정으로부터 추론될 수 있었다. 하이브리드 시스템은 네이티브 IPv7 구현이 아니면서 IPv7 주소를 가질 수 있었다. IPv4에서 IPv7로의 변환은 순방향 경로 식별자를 0으로 설정했다.

마지막 이 리셋이 중요하다. 변환기는 해석 불가능한 핸들을 아키텍처를 넘어 복사함으로써 연속성을 만들어내지 않았다. 그것은 다음 라우팅 도메인에 새로운 결정을 요구했다. 주소, 버전, 식별자, 변환기 동작, 조각들과 이후의 전달은 서로 다른 기록이었다.

문서의 이후 역사는 다른 질문에 답한다

RFC Editor 기록은 이제 RFC 1475를 Historic으로 표시한다.RFC 1752는 이후 TP/IX 노력이 CATNIP이 되었음을 기록하고, CATNIP이 선정하기에 너무 불완전하다고 판단하며, 128비트 SIPP를 IPng의 기반으로 권고했다.RFC 6814는 폐기된 IPv4 옵션을 정리하면서 RFC 1475를 공식적으로 폐기(obsolete)했다.

이 사실들은 문서적 지위의 선을 닫는다. 그것들은 누군가 구성 요소를 구현한 적이 없다는 것, 모든 아이디어가 기술적으로 무가치했다는 것, 또는 어떤 패킷이 특정 경로를 통과했다는 것을 말해주지 않는다. 반대로, 자신감 넘치는 1993년 명세와 'Next Internet'이라는 제목이 배포를 현실로 만들지는 않았다.RFC 791은 IPv4 기준선으로 남았고, 이후 권고는 다른 기반을 선택했다.

RFC 1475는 또한 보안 문제가 논의되지 않았다고 밝혔다. 그 검증 제안을 인증, 권한 부여, 무결성 또는 적대적 토큰에 대한 보호로 격상시킬 수는 없다. 로컬 핸들은 보안 자격 증명이 되지 않고도 검사될 수 있다.

출처