요약

  • RFC 1365는 고정된 출발지·목적지 주소 위치를 유지하면서, 클래스 F 주소의 나머지를 IP 헤더 옵션에서 찾도록 제안했다.
  • 문서의 상호운용성 항목은 미지원 호스트가 해당 데이터그램을 무시한다고 명시했다. 외형을 남겨 두는 일과 오래된 수신기를 작동시키는 일은 별개였다.

주소가 짧다면 늘어난 부분을 어디에 둘 것인가. Karanjit Siyan은 1992년 9월의 RFC 1365에서 이미 존재하는 IP 옵션 영역을 골랐다. 당시 클래스 기반 체계의 네트워크 번호 부족을 문제로 제시했고, 새 방식에 대한 토론을 요청했다. 이 문서는 Informational 제안이다. 운영 중인 표준의 도입 기록은 아니다.

옵션 영역에도 상한이 있었다. 헤더 길이를 나타내는 네 비트로 표현할 수 있는 최대치는 네 옥텟짜리 단어 열다섯 개다. 기본 헤더가 다섯 개를 차지해 열 개가 남는다. 저자는 그중 여섯 개를 일반 옵션에 남기고 네 개를 확장 주소 옵션에 쓰자고 했다. 새로운 공간이 생긴 게 아니라, 한정된 공간의 사용 순서를 다시 정한 셈이다.

고정된 주소 필드의 맨 앞 비트 111110은 새 클래스 F를 알린다. 같은 필드의 오프셋은 헤더 시작부터 몇 단어 뒤에 주소의 두 번째 부분이 있는지 가리킨다. 수신기는 모든 옵션을 훑지 않고 그 위치로 이동할 수 있다. 두 번째 부분은 유형·길이·값 형식을 따르며, 문서에는 F-4와 F-8 변형이 실려 있다. 새 비트 패턴을 확보하려고 예약된 클래스 E의 정의를 11110으로 좁히는 안도 포함됐다.

진짜 쟁점은 목적지의 코드였다. 수신 호스트가 F 표시를 알아보고 오프셋을 따라가 두 부분을 한 주소로 합쳐야 했다. 문서 3절은 이를 지원하지 않는 호스트가 데이터그램을 무시하며 기존 호스트와 통신할 수 없다고 적었다. 수신 측에 추가할 처리 코드도 간단히 그렸다. 저자는 이 수정이 완전히 다른 IP 헤더나 프로토콜을 도입하는 것보다 작다고 봤다. 작다는 평가가 수정이 필요 없다는 뜻은 아니었다.

같은 해의 RFC 1375에도 클래스 F라는 이름이 등장한다. 그 문서는 작은 네트워크에 맞는 주소 클래스를 제안한다. RFC 1365의 관심사는 옵션을 이용해 한 주소를 늘리는 방식과 그것을 읽지 못하는 기존 수신기다. 알파벳 하나가 같아도 서로 다른 설계다.

원문은 구상과 수신 실패 조건을 확인해 준다. 실제 채택 규모는 제시하지 않는다. 이 역사의 핵심 장면은 명확하다. 예전 모양의 헤더를 단 패킷이 도착했고, 예전 규칙을 실행하는 기계는 그 패킷을 버렸다.