요약

  • Paul Robinson의 정보성 RFC 1375는 소규모 사이트가 일반적인 클래스 C 네트워크보다 적은 수의 IPv4 주소를 사용할 수 있도록 F, G, H, K 클래스를 제안했습니다.
  • 이 제안은 주소 비트에 지역적·기기적 의미를 부여하는 방안도 검토했으나, 라우터·브리지·기타 소프트웨어가 더 작은 로컬 필드를 허용해야 한다고 명시했으며, 클래스 K의 본문 서술과 도표는 서로 일치하지 않습니다.

블록이 너무 클 수도 있었다

1992년의 주소 문제는 IPv4의 32비트 공간이 유한하다는 점만이 아니었습니다. 익숙한 네트워크 클래스에서 제공되는 크기가 조직에 맞지 않을 수 있었습니다. RFC 1375는 클래스 C 네트워크가 최대 254대의 로컬 기기를 수용할 수 있다고 서술하며, 기기를 4~5대만 운용하는 사이트는 240개가 넘는 주소를 낭비할 수 있다고 주장했습니다. 이 문서는 전화 접속에서 Telnet이나 FTP로 이동하는 BBS(게시판 시스템), 그리고 인터넷 프로토콜을 통해 접근 가능해지는 프린터, 팩스, 호출기 같은 소규모 설비의 증가하는 모습을 그렸습니다.

Paul Robinson의 해법은 클래스 경계를 다시 그리는 것이었습니다. 이 메모는 클래스 C의 선두 비트를 변경하고 그 공간의 일부를 F, G, H, K라는 네 가지 새로운 명칭에 배정할 것을 제안했습니다. 제안된 로컬 필드는 점점 작아졌습니다. 클래스 F는 대략 1~15개의 연결 주소를 가진 사이트, H는 7개를 넘지 않을 것으로 예상되는 사이트, K는 1~2개를 가진 사이트를 위한 것이었습니다. 이 수치와 네트워크 필드는 고정된 클래스 체계의 일부였으며, 임의의 프리픽스 길이를 선택하라는 일반적인 지침이 아니었습니다.

이는 네트워크 규모를 주소 구조 안에 맞추려는 시도였습니다. 레지스트리 정책도, 할당 기록도, 이 클래스들이 실제로 할당되었다는 증거도 아니었습니다. RFC 1375는 스스로를 Informational이라 칭하며 인터넷 표준을 지정하지 않는다고 명시합니다. 요약에서는 구현 방법이 아직 제공되지 않을 수 있다는 점까지 인정하면서, 해당 공간을 예약해 둘 것을 제안합니다.

진짜 과제는 호환성 조건이었다

이 메모는 새로운 비트 패턴이 저절로 작동할 것이라고 가정하지 않았습니다. 브리지, 라우터, 기타 하드웨어와 소프트웨어가 마지막 8비트가 항상 로컬 주소라고 가정하지 않고 더 작은 로컬 필드를 허용할 수 있을 때에만 이 방법이 문제를 피할 수 있다고 말합니다. 이 문장은 겉보기에 지역적인 할당 아이디어를 네트워크 전반의 호환성 문제로 바꿉니다. 주소 클래스는 그 비트의 의미를 해석·구성·라우팅·관리하는 기기들이 모두 같은 이해를 공유할 때에만 유용합니다.

RFC 1375는 블록 크기를 넘어서도 살펴봤습니다. 선택 항목으로, 국제 전화 번호 체계에 비유해 선정된 비트를 지역 라우팅 코드로 사용할 수 있다고 제안했습니다. 저자는 그 비유를 즉시 단서를 달았습니다. 인터넷 번호 자체는 지리적 장소를 식별하지 않으며, 그런 코드가 라우팅에 필요하지 않다고 했습니다. 메모의 각주는 더 나아가 호출기, 팩스, 게이트웨이 등 기기 클래스를 구분할 수 있는 주소 자릿수를 상상했습니다. 이것들은 하나의 정보성 제안에 담긴 추측적 아이디어였지, 배포된 인터넷의 기능이 아니었습니다.

한 세부 사항은 이 사양의 한계를 유난히 선명하게 드러냅니다. 본문에서 클래스 K는 7비트 프리픽스를1101111로, 25비트 네트워크 번호와 1비트 로컬 주소로 서술합니다. 그러나 함께 실린 도표는 대신110100과 26비트 네트워크 필드를 인쇄합니다. 두 서술이 같은 레이아웃을 정의할 수는 없습니다. 이 불일치는 공개된 텍스트 그 자체에 있으며, 이용 가능한 자료로는 누군가 이 제안을 구현했는지, 이 모순이 그 역사에서 어떤 역할을 했는지 확인할 수 없습니다.

소형 블록을 쓰게 만드는 또 다른 방법

1992년 기록에는 주소와 라우팅 압박에 대한 다른 대응도 담겨 있습니다. RFC 1338은 서비스 제공자를 위한 계층적 할당과 수퍼네팅을 제안했고, RFC 1366은 등록 기능과 네트워크 번호 공간의 분배를 다뤘습니다. 1993년 9월, Standards Track의 RFC 1519는 CIDR을 기술했습니다. 제공자 블록에서 자주 따오는 가변 길이, 비트마스크 기반의 할당과 경로 집계가 함께 제시된 것입니다. 이 문서는 집계가 실효성을 갖기 위해 할당 변경과 라우팅 프로토콜 변경이 함께 작동해야 한다고 강조했습니다.

이후의 접근은 모든 주소가 이름 붙은 네트워크 클래스나 선택적 지리·기기 유형을 광고할 것을 요구하지 않았습니다. 프리픽스 길이를 관련 경계로 만든 것입니다. 1995년까지 RFC 1812는 IPv4 라우터에 서브네팅과 CIDR 지원을 요구했고, RFC 1878은 개별 호스트 경로까지 가변 길이 서브넷을 표로 정리했습니다. 이후 문서들은 표준이 결국 사용한 어휘를 보여줍니다. 그러나 CIDR이 RFC 1375를 대체한 단순한 인과 관계를 증명하지도 않으며, Robinson의 제안이 표준 트랙 연속성을 얻지 못한 이유를 말해주지도 않습니다.

Lu Heng의 노트 48은 여기서 편집적 렌즈로 유용합니다. IP 주소는 우선 그 기록이 일관성을 유지해야 하는 고유한 수치 레이블로 이해될 수 있습니다. 그 렌즈는 범위에 대한 질문을 불러옵니다. 주소 자체가 얼마나 많은 것을 담고, 얼마나 많은 것이 할당 기록, 마스크, 라우팅 프로토콜, 애플리케이션 수준의 네이밍이 처리해야 하는가? RFC 1375의 답은 네트워크 규모에서 가능한 지리와 기기 클래스까지 뻗었습니다. 이후 CIDR의 답은 가변 길이 프리픽스와 집계에 집중했습니다. 그 차이는 단지 소규모 사이트가 받는 주소 수가 아니라, 인터넷이 주소 해석의 복잡성을 어디에 둘지에 관한 것이었습니다.

출처