요약

  • RFC 1380은 즉각적인 운영 완화, 단기 CIDR 작업, 주소 고갈에 대한 중기 답변, 장기 인터넷 계층 연구를 분리했습니다. 네 단계 모두 대기열에 넣지 말고 즉시 시작해야 한다고 명시했습니다.
  • 이 메모는 CIDR을 기존 주소 체계 아래에서 시간을 사는 방법으로 불렀습니다. 동시에 정책, 프로토콜, 구현, 배포 작업을 요구하면서, 임시 조치가 장기 해법에서 자원을 끌어올 수 있음도 인정했습니다.
  • 가장 오래 남는 교훈은 근거에 관한 것입니다. 권고, 둔화 지표, 전환 계획, 선정된 아키텍처, 배포된 결과는 서로 다른 주체가 소유하는 서로 다른 기록입니다.

위기에는 세 개의 시계가 있었다

1992년 11월,RFC 1380은 쉽게 뒤섞일 수 있는 세 가지 성장 문제를 기술했습니다. 클래스 B 네트워크 번호가 소진되고 있었습니다. 라우팅 정보가 라우터와 운영자의 편안한 수용 능력을 넘어 확대되고 있었습니다. 더 멀리서는 32비트 주소 공간 자체가 부족해질 수 있었습니다.

이 문제들은 원인—성장—은 공유했지만, 기한도 해법도 공유하지 않았습니다. 중간 규모 사이트에 여러 클래스 C 네트워크를 주는 것은 클래스 B 번호를 절약하면서 경로를 늘릴 수 있었습니다. 더 큰 라우터를 사는 것은 할당 구조를 바꾸지 않고 더 많은 항목을 흡수할 수 있었습니다. 더 큰 주소 공간은 수치적 고갈을 미룰 수 있지만 더 넓은 영역에서 라우팅 테이블 과부하를 재현할 수도 있었습니다.

메모는 라우팅 압박을 기계적 한계와 인간적 한계로도 나누었습니다. 메모리, 처리 능력, 업데이트 대역폭은 라우터를 제약했습니다. 구성과 트래픽 모니터링은 운영자를 제약했습니다. 전자는 하드웨어 구매로 해결될 수 있었습니다. 후자는 정책이 늘어나는 경로 수에 걸쳐 올바르게 표현되었는지 누군가 이해해야 했습니다. 장비 수와 노동 부담은 관련되어 있었지만 어느 쪽도 다른 쪽을 측정하지 않았습니다.

RFC 1380은 네트워크 번호 할당과 Merit NSFNET 라우팅 데이터베이스의 항목이 대략 12개월마다 두 배가 되었다고 보고했습니다. 이는 명명된 기간과 관측 체계에 기반한 진지한 증거였습니다. 그러나 모든 라우터의 전수 조사도, 예측이 일정대로 성숙할 것이라는 증명도 아니었습니다. 그 수치는 압박을 입증했고, 결정에는 여전히 시야가 필요했습니다.

ROAD는 숙고하기 위한 임시 장소였다

Routing and Addressing 그룹은 상설 위임을 가진 상설 표준 기구가 아니었습니다. RFC 1380은 ROAD를 Santa Fe IETF 이후에 구성되어 San Diego 회의에서 보고하도록 요청받은 일회성 특별 그룹으로 기술합니다. 이 그룹은 대면으로 만나고 전자 우편으로 논의하며 제안을 BOF, 본회의 토론과 예정된 워킹 그룹에 공급했습니다.

이 구조는 중요합니다. 임시 그룹은 긴급성을 모으고, 선택지를 비교하고, 작업을 권고할 수 있었습니다. 그러나 그것이 이후의 모든 표준, 할당 정책, 라우터 구현, 현지 이전을 자동으로 소유하는 것은 아니었습니다. 메모 자체가 Informational로 표기되어 있고 스스로를 IESG 심의의 예비 보고서라 부릅니다. 이는 진행 중인 결정 과정을 기록한 것이지, 인터넷 표준도 실행 로그도 아닙니다.

ROAD는 경로 집합을 위한 단기 방향으로 CIDR에 수렴했습니다. 그러나 San Diego에서 하나의 더 큰 주소 아키텍처에 대한 최종 권고는 내지 않았습니다. 이 비대칭은 의도된 것이었습니다. 한 문제는 충분히 경계된 개입이 가능했지만, 다른 문제는 아직 전환과 영향에 관한 충분한 증거가 없었습니다.

하나의 치료제가 모든 시계에 동시에 도착할 수는 없었다

RFC 1380은 하나의 설계가 가장 가까운 한계가 도래하기 전에 단기 라우팅 압박, 주소 고갈, 고급 인터넷 계층 기능을 모두 해결할 수 있다는 안심시키는 생각을 거부했습니다. 새로운 인터넷 계층은 대규모 설치 기반의 변경을 수반했습니다. 기술적 질문은 아직 성숙하지 않았고, 선정, 구현, 배포에는 시간이 걸렸습니다.

따라서 IESG는 최소 두 개의 주요 단계를 기술하고 네 개의 작업 수평선—즉시, 단기, 중기, 장기—을 명명했습니다. 이 라벨은 순차적으로 들립니다. 그러나 지시는 정반대였습니다. 모든 단계는 즉시 시작되어야 했고, 커뮤니티는 이들을 순차적으로 추진할 여유가 없었습니다.

이 문장은 관리 모델을 바꿉니다. “즉시”가 더 이상 모든 사람이 가장 가까운 불로 옮겨간다는 뜻이 아닙니다. 각 수평선이 마감 시점이 다르더라도 책임 있는 시작을 받는다는 뜻입니다. 그렇지 않으면 긴급한 계층이 달력을 반복적으로 소비하고, 장기 계층은 임시 체계가 그 자체로 설치 기반이 된 뒤에야 시작됩니다.

즉각 조치는 해결이 아니었다

즉시 목록에는 더 보수적인 주소 할당, 할당과 집합 사이의 정렬, 미사용 클래스 B 번호 회수, 요점 지점의 더 강한 라우터, 토폴로지 엔지니어링이 포함되었습니다. 어느 것도 새 프로토콜을 요구하지 않았습니다. RFC 1380은 어느 것도 근본 문제를 해결하지 못하며 시작을 늦출 수 있다고 명시했습니다.

이 구분은 기록을 보호합니다. 더 엄격한 할당 결정은 정책이 바뀌었음을 증명합니다. 회수된 번호는 특정 자원이 풀로 돌아왔음을 증명합니다. 라우터 업그레이드는 일부 장비 용량이 바뀌었음을 증명합니다. 한 관측 지점에서 작아진 테이블은 완화를 보일 수 있습니다. 그러나 그 어느 것 하나만으로 주소 고갈, 운영자 부담, 전환 리스크가 해결되었음을 증명하지 못합니다.

이것은 배분 문제도 드러냅니다. 보수적 할당은 증명 작업을 신청자에게, 판단을 레지스트리에 전가합니다. 토폴로지 엔지니어링은 더 작은 상태 부담을 위해 회복성이나 경로 품질을 교환할 수 있습니다. 더 강한 라우터는 비용을 운영자에게 옮깁니다. “즉시” 조치는 프로토콜 관점에서 되돌릴 수 있으면서도 오래 지속되는 행정적 기대를 만들 수 있습니다.

CIDR은 소유자 사슬을 거쳐 시간을 샀다

RFC 1338은 서프네팅을 단기 다리로 규정했습니다. 그것은 장기 답변이 개발되는 동안 클래스 B 소비와 라우팅 테이블 성장을 늦추는 것을 목표로 했습니다. 최소 3년이라는 스스로의 기대는 보증이 아니라 계획상 가정이었습니다.

개입은 하나의 스위치가 아니었습니다. 주소는 집합 가능한 경계를 따라 할당되어야 했습니다. 도메인 간 프로토콜은 임의의 네트워크-마스크 쌍을 전달해야 했습니다. 라우터는 그 의미론을 구현하고 배포해야 했습니다. 비-CIDR 도메인과 내부 프로토콜은 작동 가능한 경계가 필요했습니다. 멀티호밍과 공급자 변경은 더 구체적인 경로를 보존할 수 있었습니다. 유능한 라우팅 없이 할당 정책을 배포하면 오히려 테이블 성장을 일시적으로 가속할 수도 있었습니다.

RFC 1380은 이에 따라 프로그램을 분산시켰습니다. 운영적 주소 계획, BGP 작업, 가능한 IDRP 작업, 명시적 배포 계획이 그것입니다. 이 메모는 CIDR을 기존 주소 체계 아래에서 라우팅 테이블 폭발을 다루고, 클래스 B 압박의 중요성을 낮추고, 시간을 사는 방법으로 불렀습니다. 그러나 그 구매가 무료라고 하지는 않았습니다.

RFC 1519는 이후 CIDR 사양을 개정하면서 다리라는 언어를 유지했습니다. 개정된 문서는 계획의 성숙을 증명합니다. 그러나 실제 완화는 여전히 구현, 참여, 토폴로지, 관측 지점, 시간에 달려 있습니다.

다리는 목적지를 소모할 수 있었다

RFC 1380은 두 가지 장기 비용을 이례적으로 뚜렷하게 만들었습니다. 첫째, 인터넷 계층을 교체하거나 확장하는 것은 벤더, 운영자, 사용자에게 충격적일 것이었습니다. 따라서 단기·중기 작업은 그 충격을 최소화하거나 매끄러운 전환 경로를 보존해야 했습니다. 국지적으로 성공한 다리도, 출구를 더 어렵게 만든다면 전략적 실패일 수 있었습니다.

둘째, 임시 개발과 배포는 장기 해법을 포함한 다른 프로젝트에서 자원을 끌어올 것입니다. 이는 인력 배치에 관한 각주가 아닙니다. 기회 비용에 관한 주장입니다. 같은 엔지니어, 테스트베드, 운영자 관심, 변경 창은 예산이 서로 다른 항목으로 기술한다고 해서 두 번 배정될 수 없습니다.

따라서 사들인 시간은 쓴 시간과 나란히 기록되어야 합니다. 단기 조치가 18개월의 용량을 더하지만 2년의 이전 작업을 흡수한다면, 그 표면적 이득과 프로그램 효과는 서로 다른 방향을 가리킵니다. RFC 1380은 그 이후의 측정을 제공하지 않았습니다. 다만 조치를 선택하기 전에 그 전용을 고려할 것을 주장했습니다.

기준이 더 큰 주소 결정보다 앞섰다

IESG는 전환 증거가 불완전할 때 더 큰 주소 제안을 선택하지 않았습니다. RFC 1380은 운영 인프라, 기존 프로토콜에 미치는 영향, 새로운 라우팅, 주소 할당, 성능, 변경 통제 소유권, 관리, 보안, 교육 비용을 명명했습니다. 부록 B는 각 제안이 항목별로 응답하고, 영향받는 장치와 기능별로 변경을 묶으며, 구현 경험을 공개할 것을 요구했습니다.

이는 절차로 위장한 우유부닮함이 아니었습니다. 긴급성은 기한을 정했지만, 긴급성이 매력적인 제안을 이전에 관한 증거로 바꾸지는 않았습니다. 제안 요청, 인터넷 초안, 공개 검토, 발표, IESG 권고, IAB 결정은 별개의 산물로 남았습니다. 일정표는 누가 무엇을 만들어야 하는지 기술했습니다. 결과를 사전에 인증하지 않았습니다.

이후의 권고는 별개의 행위로 남았다

결정 과정은 RFC 1380 안에서 끝나지 않았습니다.RFC 1719는 이후 IPDecide BOF가 확고한 방향의 부재를 부각시켰다고 기록했습니다. 그것은 IPng 권고 개발 책임을 IESG에 두고, 공개되고 사전 고지된 절차를 요구하며, 긴급성 추정을 할당률, 정책 효과, 예상 CIDR 절감, 새 IP의 개발·현장 적용·이전에 필요한 시간과 연결했습니다.

1995년 1월,RFC 1752는 이후의 권고를 문서화했습니다. 개정된 SIPP 제안을 IPng의 기초로 선택하고, 프로토콜, 자동 구성, 전환, 공존 작업을 분리했으며, 버전 번호 6이 IPv6로 불릴 것이라고 기록했습니다.

그 이후의 선택은 1992년 메모를 숨겨진 IPv6 결정으로 바꾸지 않습니다. 오히려 반대를 증명합니다. 장기 선정에는 또 다른 절차, 더 넓은 증거 꾸러미, 새로운 책임 권고가 필요했습니다. 권고가 보편적 이전이나 IPv4의 은퇴를 증명하지도 않습니다. 선정, 사양화, 배포, 결과는 각자의 시계를 유지했습니다.

출처와 한계

이 글은 RFC 1338, RFC 1380, RFC 1519, RFC 1719, RFC 1752의 공식 텍스트를 사용합니다. 이들은 당대의 문제 정의, 권고, 기준, 문서 계보를 확립합니다. 그러나 명명된 현재 네트워크의 상태, 모든 예측의 정확성, 모든 이정표의 완수, 특정 구현, 승인된 현지 변경, 측정된 운영 결과를 확립하지 않습니다.

경계된 결론은 더 좁습니다. 1992년 인터넷의 수호자들은 긴급 완화와 장기 교체를 하나의 프로젝트로, 혹은 연속된 프로젝트로 다룰 수 없다고 문서화했습니다. 임시 조치에는 이득 기록, 자원 대장, 출구 경로가 필요했습니다. 세 가지 모두 없다면, 체계는 사들인 시간은 세면서 미래를 어디에 쓰고 있는지 놓칠 수 있었습니다.