요약

  • RFC 1476은 수신 경로가 이후의 운명에 이르기까지 다섯 단계의 로컬 절차를 거친다고 기술했다. 수신자 필터링, 메트릭과 옵션 처리, 집계, 포워딩 데이터베이스를 위한 활성 경로 선택, 피어별 송신 필터링이다.
  • 옵션 클래스, 소스 제한, 정책 태그를 통해 경로를 로컬에서 사용하거나, 제거하거나, 보류하거나, 폐기하거나, 다르게 내보낼 수 있었지만, 어떤 광고도 포워딩·전달·배포의 증거가 되지는 않았다.

광고는 선택의 기계 속으로 들어갔다

RFC 1476에서 라우팅 정보는 곧바로 포워딩 테이블에 들어가지 않았다. RAP 피어, 정적 구성, 인터페이스, 다른 프로토콜로부터 도착했다. RAP 프로세스는 먼저 후보 경로의 데이터베이스를 구축했다. 그 데이터베이스에서 IP 포워딩 데이터베이스에 들어갈 활성 경로를 선택했다. 그 후에야 각 피어에게 어떤 활성 경로를 광고할지 결정했다.

문서는 이 아키텍처를 흐름으로 그렸다. 수신 경로는 근접 필터링과 집계를 만났다. 그 결과로 생긴 경로 데이터베이스가 선택된 활성 경로 집합에 공급되었다. 출력 필터링이 이어서 광고될 경로를 만들어냈다. 정적 경로와 RIP 같은 프로토콜에서 학습한 경로는 서로 다른 지점에서 들어왔다. 이 다이어그램이 역사적으로 유용한 이유는 네트워크 근거에서 가장 고질적인 오류 하나, 즉 컨트롤 플레인에서 수신한 메시지를 데이터 플레인에 설치된 상태의 증거로 취급하는 오류를 부정하기 때문이다.

RAP는 1993년 6월에 인터넷 표준이 아닌 실험(Experimental)으로 발표되었다. 격리된 LAN부터 국제 캐리어에 이르는 규모를 아우르는 하나의 공개 거리 벡터 프로토콜을 제안했다. 이 설계는 정책이 강제하는 경우를 제외하면 고정된 내부·외부 경계를 피했다. 토폴로지 정보의 넓은 배포를 장려했고, 대역폭·처리 능력·행정 정책이 요구할 때만 집계를 허용했다.

이는 야심 찬 설계 주장이었다.RFC Editor 기록은 그 문서적 지위를 보존하고 있다. 그러나 야심도 기록도 동작 중인 라우터로부터의 영수증은 제공하지 않는다.

첫 번째 결정: 제안이 수신을 통과했는가

수신자 필터링은 제안된 경로가 너무 멀거나 너무 구체적인지 물었다. 보편적 연결성을 필요로 하는 라우터는 모든 유한 경로를 수용하고 집계로 축소하거나, 그렇게 하는 라우터로의 기본 경로에 의존해야 했다. 자원이 제한된 라우터는 필터를 동적으로 좁힐 수 있었다.

문서는 되돌릴 수 없는 지점도 기록했다. 운영자가 나중에 필터를 넓히더라도, 앞서 폐기된 경로는 다시 사용할 수 없을 수 있다. 그것을 광고했던 피어들이 그것을 반복할 의무가 없기 때문이다. 더 넓은 조리개가 사라진 메시지를 재구성하지는 않는다.

이 구분은 RAP를 넘어 중요하다. 구성 상태는 경로가 이제 수용될 것이라 말할 수 있다. 그러나 경로가 존재한다는 것을 증명할 수는 없다. 이를 입증하려면 관찰자는 이후의 제안, 보존된 사전 필터 기록 또는 갱신 메커니즘이 필요하다. 정책 수정과 후보 경로는 별개의 근거 객체다.

두 번째 결정: 어떤 속성이 경로를 바꾸는가

수신 이후 RAP는 경로의 메트릭과 옵션을 갱신했다. 거리는 증가했다. 지연과 비용은 누적됐다. MTU와 대역폭은 경로상의 최솟값을 취했다. 알려진 정책 옵션은 거부를 유발할 수 있었다. 알 수 없는 옵션은 간결하지만 결과가 큰 클래스 규칙을 발동했다.

RAP 헤더의 거리를 제외하면, 구현은 특정 메트릭이나 옵션을 이해할 의무가 없었다. 각 옵션은 모르는 구현에 무엇을 해야 할지 알려주는 클래스를 담았다. 클래스 0은 옵션을 그대로 보존하며 경로를 사용하고 전파하라는 뜻이었다. 클래스 1은 옵션을 생략하고 사용 및 전파하라는 뜻이었다. 클래스 2는 로컬에서만 사용하고 전파하지 말라는 뜻이었다. 클래스 3은 경로를 폐기하라는 뜻이었다.

이는 신뢰 비트가 아니었다. 송신자를 인증하지 않았고, 값을 검증하지 않았으며, 지시가 안전하다는 것을 증명하지도 않았다. 클래스와 옵션 타입은 서로 독립적이었고, 두 구현이 같은 타입에 서로 다른 클래스를 붙일 수 있었다. 포맷 필드는 알 수 없는 값을 의미가 이해되지 않은 채 문제 해결을 위해 출력 가능하게 만들 수 있었다. RFC 1476은 클래스 1에 기밀성이 없음까지 경고했다. 구현이 타입을 null 옵션으로 교체하고 나머지를 전달할 수 있었기 때문이다.

이 메커니즘은 나중에 등장한 IPv6의 미지 옵션 동작 비트나 BGP의 불투명한 옵셔널 트랜짓 속성과도 다르다. 여기서 유용한 역사적 지점은 규칙이 RAP의 더 큰 결정 사슬 안에서 차지하는 위치다. 인식되지 않은 속성 하나가 경로가 로컬에 남을지, 피어 경계를 넘을지, 완전히 사라질지를 바꿀 수 있었다.

같은 의미가 아니었던 세 가지 정책 주장

RFC 1476의 속성 목록은 이 구분을 구체적으로 만든다. Source Restriction 옵션은 어떤 패킷 소스가 경로를 사용할 수 있는지를 기술했다. 명세는 포워딩 계층의 보안 필터가 경로 정보에 반영되어야 한다고 했다. 그렇지 않으면 트래픽이 겉보기에 더 나은 경로를 선택해 필터에서 조용히 폐기될 수 있기 때문이다.

치료 자체에도 노출이 있었다. 제한을 전파하면 보안 구성에 대한 기밀 정보가 드러날 수 있었다. 문서는 경로 사용을 승인받은 네트워크를 향한 신중한 전파에 의존했다. 의도된 경계를 명시했지만, 모든 구현과 토폴로지가 그 경계를 지킨다는 것을 증명하지는 않았다.

AUP 옵션은 다른 일을 했다. 예를 들어 제한된 네트워크를 통해 상업 트래픽이 지나가는 일을 막기 위해, 경로가 조직의 허용 사용 정책에 따라서만 사용될 수 있음을 표시할 수 있었다. RFC는 이것이 포워딩 필터 같은 보안 장벽이 아니라 협력적 정보라고 명시적으로 말했다.

Public 옵션은 목적지 외의 수신자가 트래픽을 읽을 수 있는 브로드캐스트 매체를 통과하는 경로를 표시했다. 그 목적은 매력적인 대역폭이 사적 운송으로 오해되지 않도록 하는 것이었다. 소스 승인, 협력적 사용 정책, 도청 노출은 서로 다른 세 가지 주장이었다. 이를 하나의 일반적인 "정책 속성"으로 뭉치면 각각이 알려주려던 결정이 사라진다.

세 번째 결정: 상세 정보가 집계될 수 있는가

RAP은 이어서 집계를 고려했다. 같은 피어를 통과하는 경로들은 때때로 하나를 포괄하는 경로 아래 통합될 수 있었지만, RFC는 모든 경우에 자동 집계를 거부했다. 더 많은 상세 정보는 반대편 순방향 경로 식별자의 효과를 높일 수 있었다. 정책 속성은 집계를 금지하거나, 요약 대신 경로를 폐기하게 만들 수 있었다.

따라서 집계는 근거의 표면을 바꿨다. 넓은 경로를 받은 하류 피어는 더 구체적인 기여 경로들이 모두 같은 속성을 가졌다고, 나아가 기여 경로들이 개별적으로 여전히 보인다고 가정할 수 없었다. 반대로 로컬 데이터베이스에 더 구체적인 후보가 존재한다고 해서 그것이 다음 경계를 넘었다는 증거는 아니었다.

RFC 1338은 당시의 주소 집계 압박을 보여준다. RFC 1476은 여기에 자체적인 정책 인식 선택을 더했다. 그렇다고 해서 RAP가 나중의 도메인 간 라우팅의 배포된 형태가 되는 것도, 모든 요약이 의미상 중립이 되는 것도 아니다.

네 번째 결정: 경로가 활성화되는가

집계 이후 라우터는 남은 후보들을 RIP 같은 다른 메커니즘으로 학습한 경로와 결합했다. 그런 다음 어떤 경로가 IP 포워딩 데이터베이스에 들어가 실제로 데이터그램을 전달할 자격이 될지를 선택했다. 로컬 정책은 속성과 옵션의 어떤 조합이든 사용할 수 있었다.

이것이 경로 데이터베이스와 활성 포워딩 상태를 가르는 결정적 경계다. RAP 프로세스는 여러 후보를 유지하면서 하나만 설치할 수 있었다. 제한 없는 경로를 선호하면서 제한된 대안을 보존할 수 있었다. 비용, 매체, 소스 조건, 행정 태그가 로컬 정책과 충돌하는 경로를 거부할 수 있었다.

RFC 1058과RFC 1247은 거리 벡터 및 링크 상태 라우팅의 당시 참조점이었다. RFC 1476의 저자들은 그러한 경로와의 상호작용을 제안했지만, 어떤 프로토콜로부터의 수신을 선택과 동등하게 만들지는 않았다. 컨트롤 플레인 데이터베이스 스냅샷조차도 패킷이 설치된 항목과 일치했는지, 인터페이스를 떠났는지, 목적지에 도달했는지를 증명하지 못했다.

다섯 번째 결정: 다음에 누가 이를 들을 수 있는가

송신 필터링은 활성 선택 이후에 왔다. RAP는 활성 경로의 부분집합만 광고할 수 있었고, 피어마다 다른 부분집합을 고를 수 있었다. 임의의 로컬 정책이 그 결정들을 통제했다.

순서가 중요하다. 어떤 경로는 로컬 포워딩에는 활성이면서도 한 피어의 시야에서 의도적으로 빠져 있을 수 있었다. 다른 경로는 속성 하나를 제거한 채 내보내질 수 있었다. 세 번째 경로는 알 수 없는 클래스가 전파를 금지해 보류될 수 있었다. 외부에서 보이는 라우팅 표면은 활성 로컬 상태의 투영이지 그것의 거울이 아니었다.

송신자는 또한 피어들이 트래픽을 블랙홀로 보내지 않도록 제공되는 경로 안에 패킷 필터를 반영해야 했다. 이는 규범적 의무였다. 광고가 존재했다는 근거는 그 반영이 완전했는지, 하류 선택이 올바른지, 패킷이 필터를 벗어났는지를 증명하지 못했다.

살아 있는 TCP 연결은 살아 있는 라우팅 프로세스가 아니었다

RAP의 전송 메커니즘에는 같은 주의가 다른 계층에서도 담겨 있었다. 피어들은 포트 38에서 하나의 대칭 TCP 연결을 사용했고, 각 명령을 상대에게 확인 응답하지 않은 채 양방향으로 경로 명령을 주고받았다. 애플리케이션 계층의 Poll과 No Operation 교환이 피어별 타이머를 초기화했다.

RFC 1476은 TCP keepalive만에 의존하는 것을 권하지 않았다. 그것은 원격 TCP가 데이터를 수용한다는 것만 보여줄 뿐, 원격 RAP 프로세스가 살아 있음을 보여주지 않았기 때문이다. 연결이 끊어지면 각 측은 그 피어로부터 학습한 모든 경로를 제거해야 했다. 회선, TCP 엔드포인트, RAP 프로세스, 경로 데이터베이스, 포워딩 상태는 다시금 별개였다.

루프 복구에도 한계가 있었다. RAP는 거리 제한과 선택적 추적 속성을 사용했고, 최후의 루프 절단을 신속하기보다 결국 일어나는 것으로 기술했다. 계속 반복되는 오류는 루프를 재생성할 수 있었다. "자가 치유"는 수렴 시간의 측정이 아니었다.

이 실험적 설계가 확립할 수 있는 것

짝을 이루는RFC 1475와 그RFC Editor 기록은 TP/IX 환경과 순방향 경로 식별자를 기술한다. 그 식별자의 홉 전용 의미와 RAP Add/Purge 타이밍은 이전 위원회가 소유한다. 본 근거는 다르다. RFC 1476은 제안이 상태와 가시성을 바꿀 수 있는 일련의 권한 표면을 명시했다.

RFC 2026은 표준 라벨을 운영적 증거로 바꾸지 않으면서 읽는 데 도움이 된다. 이 제안이 주목받을 만한 이유는 격차를 명시적으로 만들었기지, 발표가 그것을 해소했기 때문이 아니다.

바로 이것이 Lu Heng의실행 코드 우위,최소 초기 명세와 국소적 미래 결정,현실의 계층에 관한 에세이와 이어지는 지점이다. 경로 광고는 로컬의 고려를 촉발할 수 있다. 그러나 이후의 필터, 선택자, 포워딩 테이블, 피어 내보내기, 관찰된 애플리케이션 결과의 권위를 빌릴 수는 없다.

출처