요약

  • RFC 1481은 주소 및 라우팅 테이블 압박에 대한 즉각적 대응으로 CIDR을 승인하면서, 서로 다른 장기 해법이 여전히 추구되고 있다고 명시적으로 전제했다.
  • 두 페이지 분량의 권고문은 IAB, IANA, InterNIC, 라우터 벤더, 네트워크 운영자에 걸쳐 분산된, 상호 의존적인 주소 할당 및 경로 집계 작업을 명명했다. 어느 주체의 문서도 다음 주체의 실행을 증명하지 못했다.

IAB가 승인했을 때 무엇이 달라졌는가

RFC 1481은 이례적으로 짧다. 스케일링 문제를 서술하고, CIDR의 두 기본 구성 요소를 식별하고, 위험한 전환에 대해 경고하며, 구현에 대한 지지를 기록한다. 이 간결함 때문에 그 동사들이 그 밑바닥의 운영 체계보다 더 결단력 있어 보인다.

첫 번째 동사는 제도적이었다. IAB는 아키텍처와 그 구현을 승인했다. 이는 기술 커뮤니티에 공개된 조정 지점을 제공했다. CIDR이 추구할 가치가 있는 조치에 속하는지에 대한 불확실성을 줄였고, 레지스트리가 새로운 할당 관행을 정당화하고, 벤더가 엔지니어링의 우선순위를 정하고, 운영자가 업그레이드를 계획하는 데 도움이 될 수 있었다.

그러나 그 행위는 경계가 있었다. 이 메모는 인터넷 표준이 아니라 인터넷 커뮤니티를 위한 정보로서 자신을 서술했다. 그RFC Editor 기록은 현재 이를 Historic으로 표시하는데, 이는 1993년 7월의 네트워크에 대한 측정이 아니라 후대의 목록 판단이다. 어느 쪽 지위도 특정 프리픽스가 토폴로지 기준으로 할당되었는지, 라우터가 마스크를 수용했는지, 운영자가 애그리게이트를 구성했는지, 피어가 그것을 전파했는지, 디폴트프리 테이블이 작아졌는지를 답하지 않는다.

승인은 공통 기록을 바꿨다. 다른 변화들은 다른 곳에서 일어나야 했다.

다리는 의도적으로 목적지가 아니었다

RFC 1481은 CIDR을 32비트 IPv4 공간의 유효 수명을 연장하는 “즉각적 전략”이라고 불렀다. 동시에 커뮤니티가 적합한 장기 해법을 다루고 있다고 전제했다. 이 조항들은 후대 독자가 CIDR을 모든 스케일링 문제의 답으로 만드는 것을 막는다.

RFC 1338은 세 가지 압박을 구분했다: B 클래스 번호의 고갈, 소프트웨어와 사람이 관리할 수 있는 수준을 넘어서는 라우팅 테이블 성장, 그리고 32비트 공간 전체의 궁극적 고갈. 그 제안은 앞의 두 가지 시급한 문제를 공략하고 세 번째를 위한 시간을 벌었다.RFC 1380은 이 다리를 더 넓은 ROAD 의제 안에 배치했다.

이 구분은 전략적이었다. 잠정 조치는 최종 아키텍처가 아니면서도 없어서는 안 될 수 있다. 그 성공은 판단 시간을 벌어주지만, 바로 그 성공이 대체물을 만들어야 하는 사람들이 느끼는 긴박감을 줄일 수도 있다. RFC 1481을 정확히 읽으려면 두 개의 시계가 필요하다: CIDR 작업이 얼마나 빨리 시작되어야 했는가, 그리고 그 밑에 있는 주소 한계가 얼마나 오래 미해결로 남았는가.

이후의RFC 1752는 IPng 권고를 기록한다. 그 이후의 선택을 RFC 1481에 거슬러 투영할 수는 없다. 1993년 7월, 짧은 메모는 다리를 승인하고 아직 열려 있는 목적지를 인정했다.

할당과 집계는 함께 움직여야 했다

RFC 1481은 CIDR을 두 기본 구성 요소, 즉 인터넷 주소 공간의 할당 관리와 라우팅 정보를 집계하는 방법 제공으로 축소했다. 이 표현은 독립적 개선 항목의 목록이 아니라 결합된 시스템을 서술한다.

토폴로지를 고려하지 않고 네트워크 번호를 흩뿌리는 대신, 할당 측은 프로바이더 또는 지역 단위로 연속된 블록을 발급할 수 있었다. 그러면 라우팅 측은 많은 고객 네트워크를 커버하는 하나의 프리픽스를 광고할 수 있었다. 디폴트프리 라우터는 더 적은 개별 엔트리를 유지하게 된다.

그러나 메모는 이 결합을 날카로운 부정형으로 표현했다. 집계 없이 C 클래스 번호 블록을 할당하면 라우팅 테이블을 폭발시킬 수 있다는 것이었다. 프로토콜과 소프트웨어 작업이 뒤처지면 행정 개혁은 그것이 완화하려 했던 운영 문제를 오히려 악화시킬 수 있었다.

RFC 1338은 이미 같은 의존 관계를 더 상세히 서술한 바 있었다. 새로운 주소 계획은 거의 즉시 시작할 수 있었지만, 효과적인 집계에는 도메인 간 프로토콜의 변경이 필요했다. 슈퍼네팅 가능한 프로토콜이 있어도 할당 계획이 없다면 집계할 유용한 구조가 거의 없었다. 그 프로토콜 없는 할당은 일시적으로 테이블 성장을 가속할 수 있었다.

이 때문에 정책 출판물은 배포 영수증으로 서는 안 된다. 그것은 할당 규칙이 승인되었음을 증명할 수는 있지만, 라우터가 임의 프리픽스 길이를 이해했는지, 그 기능을 담은 릴리스가 프로덕션에 도달했는지, 운영자가 의도된 요약을 구성했는지, 인접 네트워크가 그것을 수용했는지는 증명할 수 없다.

레지스트리 경로는 누가 무엇을 발급하는지 바꿨다

RFC 1466은 IANA, 인터넷 레지스트리 및 지역 레지스트리를 통한 주소 공간 관리를 서술했다. 지역 레지스트리는 편향되지 않고 널리 인정받기를 기대했으며, C 클래스 블록 할당을 지리적 집계와 연결했다.RFC 1367은 관리 지침을 실행에 옮기기 위한 일정을 제공했다.

이들은 기술적 결과를 지닌 거버넌스 수단이었다. 할당 기록은 어떤 조직을 프로바이더 또는 지역에 의해 요약되기 위한 블록 안에 배치할 수 있었다. 그 선택은 나중에 어떤 애그리게이트가 그것을 포함할 수 있는지, 조직이 프로바이더를 바꾸면 어떤 예외가 나타날지, 얼마나 많은 리넘버링 압박이 누적되는지를 결정했다.

그러나 “할당 시스템이 바뀌었다”는 명제는 그 자체의 근거를 필요로 한다. 지침은 적용되는 계획을 보여준다. 날짜가 찍힌 레지스트리 기록은 그 계획 하에 발급된 블록을 보여준다. 위임 기록은 어느 권한이 그것을 하위 할당할 수 있었는지 보여준다. 그 어떤 기록도 라우터가 무엇을 광고했는지 보여주지 않는다.

레지스트리 경로에는 마스크가 해결할 수 없는 제도적 질문도 있었다: 누가 할당하도록 인정받았는가, 중립성이 어떻게 유지되었는가, 어떤 수요가 문서화되었으며 희소한 공간이 어떻게 보전되었는가. CIDR은 단지 프리픽스를 영리하게 인코딩한 것이 아니었다. 주소 행정을 라우팅 확장성의 일부로 만든 것이다.

벤더 경로는 아키텍처를 실행 가능한 동작으로 바꿨다

RFC 1481은 라우터 벤더의 행동을 명시적으로 지지했다. 그 한 줄은 별개의 병목을 인정한 것이다. 클래스리스 아키텍처는 패킷과 경로 문법이 설명되었다고 해서 그냥 돌아가지 않았다.

구현은 선행 비트에서 클래스를 추론하는 것이 아니라 마스크를 붙인 목적지를 저장해야 했다. 최장 프리픽스 매칭, 올바른 집계 및 역집계 동작, 그리고 클래스리스 도달 가능성을 전달할 수 있는 라우팅 프로토콜이 필요했다. 호환되는 관리 인터페이스, 업그레이드 경로, 그리고 출시 후 발견된 결함에 대한 수정도 필요했다.

이후의RFC 1518 기록은 더 완전한 주소 할당 아키텍처를 보존하며,RFC 1519 기록은 CIDR 할당 및 집계 사양을 보존한다. 출판은 구현이 무엇을 해야 하는지 명확히 했다. 그러나 어느 소스 트리에 코드가 있었는지, 어느 바이너리가 테스트를 통과했는지, 어느 하드웨어가 그것을 실행할 수 있었는지, 배포된 버전에 어떤 결함이 남았는지는 식별하지 않았다.

따라서 벤더 발표 역시 또 하나의 경계가 있는 사실이다. 릴리스 노트는 가용성을 확립할 수 있다. 빌드 해시와 테스트 결과는 아티팩트의 속성을 확립할 수 있다. 그러나 어느 쪽도 특정 네트워크에의 설치를 확립하지는 않는다.

운영자 경로는 네트워크가 무엇을 노출하는지 결정했다

네트워크 운영자는 여전히 릴리스를 선택하고, 변경을 일정에 맞추고, 정책을 구성하고, 피어와 동작을 협상해야 했다. 운영자는 클래스리스 지원 소프트웨어를 보유하면서도 더 구체적인 경로를 계속 광고할 수 있었다. 프로바이더는 넓은 애그리게이트를 시작하면서도 멀티홈 고객을 위한 예외를 보존할 수 있었다. 이웃은 프리픽스를 필터링하거나 서로 다른 정책을 유지할 수 있었다.

RFC 1338은 깔끔한 다이어그램에 구멍이 생기는 이유를 설명했다. 멀티홈 사이트는 두 개 이상의 프로바이더로부터 명시적 광고가 필요할 수 있었다. 프로바이더 사이를 이동하는 조직은 리넘버링할 때까지 구체적 경로가 기존 애그리게이트를 뚫고 남아 있을 수 있었다. 이들은 무지에서 비롯된 이탈이 아니라, 연속성·경쟁·복원력에 대한 선택에서 비롯된 결과였다.

RFC 1482의 기록은 하나의 구체적 운영 환경, 즉 NSFNET에서의 CIDR 계획을 가리킨다. 그 계획은 책임을 프로바이더 데이터베이스와 집계 과정 안에 위치시키는 데 도움이 된다. 그것을 인터넷 전체의 인구조사로 착각해서는 안 된다.

운영자의 현실에는 기기와 피어의 영수증이 필요하다: 설치된 버전, 구성 리비전, 후보 및 활성 경로, 포워딩 상태, 정확한 광고, 필터, 타임스탬프. 그런 관찰조차 그것만으로 글로벌 테이블 성장이 둔화되었다는 것을 증명하지 못한다. 그 결론은 알려진 커버리지와 방법론을 지닌 시계열 측정을 필요로 한다.

네 주체, 최소 여섯 개의 영수증

RFC 1481의 네 가지 공개 역할은 사슬처럼 읽힐 수 있지만, 명령의 위계로 읽혀서는 안 된다. IAB는 권고를 제공했다. IANA와 InterNIC은 주소 관리를 수행했다. 벤더는 구현을 제공했다. 운영자는 그 구현을 동작 중인 네트워크의 일부로 만들었다. 상호 연결된 피어들은 각자의 정책을 행사했고, 관측자들은 전체 시스템을 측정했다.

각 인수 단계는 요구되는 근거의 종류를 바꾼다:

  1. 권고문은 승인을 증명한다;
  2. 할당 대장은 자원 결정을 증명한다;
  3. 버전이 붙은 빌드와 테스트는 실행 가능한 역량을 증명한다;
  4. 설치 및 구성 기록은 로컬 배포를 증명한다;
  5. 피어 관측은 경계를 넘는 전파를 증명한다;
  6. 측정된 라우팅 데이터는 시스템 수준의 결과를 뒷받침한다.

영수증 하나를 건너뛰는 것은 단지 신뢰를 약화시키는 것이 아니다. 그것은 명제 자체를 바꾼다. “IAB가 CIDR을 지지했다”, “이 라우터가 CIDR을 지원했다”, “이 프로바이더가 애그리게이트를 광고했다”, “CIDR이 테이블 성장을 억제했다”는 네 개의 서로 다른 역사적 문장이다.

바로 이 점에서 RFC 1481을 Lu Heng의실행 코드 우위,국지적 결정과 자발적 채택,현실의 층위에 관한 에세이와 함께 읽는 것이 가치를 지닌다. 공개된 권고는 실제 상징적 권력을 지녔다. 그러나 그 운영적 성취는 독립된 당사자들이 이후의 결정을 만들고, 기록하고, 노출하는 데 달려 있었다.

RFC 1481의 보안 절은 이 메모가 보안 문제를 다루지 않는다고 밝혔다. 그 문서의 위대한 주제는 조정이었다. 그것은 인터넷을 복종시키지 않았다. 대신, 구현이 실제로 존재하는 자리에 구현을 남겨 둔 채, 공유된 방향을 읽을 수 있게 만들었다.

출처