요약

  • RFC 791은 8비트 프로토콜(Protocol) 필드를 상위 프로토콜 선택자로 정했지만, 그 값의 의미는 별도의 Assigned Numbers 체계에 위임했습니다.
  • RFC 3232는 낡은 주기적 RFC 스냅샷을 IANA의 온라인 데이터베이스로 대체했고, RFC 5237은 이후 유한한 256개 값의 이름 공간을 둘러싼 할당 정책을 강화했습니다.

IPv4 수신자는 페이로드만 들여다본다고 해서 모든 페이로드의 의미를 알 수 없습니다. 데이터를 TCP, UDP, ICMP 또는 다른 상위 프로토콜에 넘기기 전에 합의된 선택자가 필요합니다. RFC 791은 그 선택자를 프로토콜(Protocol)이라는 8비트 필드에 담았습니다. 이 필드는 다음에 무엇이 오는지를 알려줍니다. 이름이나 버전이 붙은 스키마, 구현체를 찾는 지침을 담고 있지는 않습니다.

이 작은 설계 선택은 제어 표면을 둘로 나누었습니다. IPv4 헤더는 필드의 위치와 폭을 고정했습니다. 별도의 기관이 그 필드가 가질 수 있는 값에 의미를 부여했습니다. RFC 791은 완전한 표를 인터넷 프로토콜 명세 안에 고정시키는 대신, 명시적으로 독자를Assigned Numbers로 안내했습니다. 패킷은 번호를 담았고, 커뮤니티는 사전을 관리했습니다.

외부 어휘 체계를 가진 고정 옥텟

이 분리가 중요했던 이유는 와이어 형식과 프로토콜 목록이 서로 다른 속도로 변하기 때문입니다. 새로운 상위 프로토콜에 번호가 부여될 때마다 IPv4를 다시 쓴다면 안정적인 기본 헤더가 계속 늘어나는 운영 카탈로그와 얽혀 버립니다. 별도의 할당 표를 두면 옥텟은 파싱 가능한 상태를 유지하면서 어휘는 진화할 수 있었습니다.

필드는 8비트 폭뿐입니다. 그 결과는 무한한 이름 체계가 아니라 256가지의 비트 패턴입니다. 어떤 값은 수신자를 프로토콜 처리기로 향하게 할 수 있지만, 그 처리기의 존재 여부를 협상하지는 않습니다. 전송 계층 포트가 애플리케이션을 식별할 수 있는 것과 달리 애플리케이션을 식별하지도 않습니다. 캡슐화된 데이터를 인증하거나 중간 장비가 이를 허용할 것을 보장하지도 않습니다. 송신자, 수신자, 문서, 레지스트리가 같은 의미에 동의할 때만 유용해지는 전역적으로 조율된 디멀티플렉싱 지시일 뿐입니다.

당시의 발행 체계는 인터넷의 초기 행정 규모를 그대로 반영했습니다. RFC 3232에 따르면 1977년 11월부터 1994년 10월까지 IANA는Assigned Numbers라는 제목의 RFC 형태로 프로토콜 파라미터 할당 표를 주기적으로 발행했습니다. 그 연속물의 마지막 문서인 RFC 1700은 1994년 10월의 Standard 상태 스냅샷이었습니다.

스냅샷이 권위를 잃은 순간

스냅샷은 그 밑바닥 이름 공간이 바뀌는 순간 낡습니다. 2002년이 되자 RFC 3232는 1994년 이후 이미 이루어진 변화를 명시할 수 있었습니다. Assigned Numbers RFC 시리즈가 온라인 IANA 데이터베이스로 대체되었다는 것입니다. RFC 3232는 RFC 1700을 공식적으로 Historic으로 지정하고, 옛 표가 불완전하며 어떤 경우에는 틀리기까지 했다고 경고했습니다.

이것은 IPv4 패킷의 변경이 아니었습니다. 어떤 필드도 넓어지지 않았고, 어떤 라우터도 데이터그램마다 웹사이트를 조회할 필요가 없었습니다. 바뀐 것은 현재의 조율 진실이 어디에 놓이는가였습니다. 구현자와 표준 저자들은 여전히 안정적인 명세를 인용할 수 있었지만, 권위적인 할당 집합은 레지스트리가 바뀔 때마다 새로운 아카이브 RFC 스냅샷을 만들지 않고도 유지될 수 있었습니다.

이 구분은 놓치기 쉽습니다. RFC와 레지스트리가 모두 목록처럼 보이기 때문입니다. 그러나 두자의 시간적 역할은 다릅니다. 표준 문서는 정해진 발행 시점에서 프로토콜 규칙을 기록합니다. 살아 있는 레지스트리는 공표된 정책에 따라 항목이 추가되거나 수정될 수 있는 이름 공간의 현재 할당 상태를 기록합니다. RFC 3232는 인터넷 프로토콜 파라미터에 대해 이 구분을 명시적으로 만들었습니다.

희소성이 등록을 정책으로 만들다

표를 온라인으로 옮겼다고 해서 이름 공간이 풍부해지지는 않았습니다. RFC 5237은 2008년에 프로토콜 필드를 다시 다루며 256개 값 중 55퍼센트가 이미 사용 중이라고 밝혔습니다. IETF 표준 트랙 밖의 실험과 활동을 포함해 새 프로토콜에는 여전히 번호가 필요했지만, 불필요하게 할당될 수는 없었습니다.

그 문서는 따라서 할당을 공유 인프라에 대한 판단으로 다루었습니다. 검토할 물음에는 안정적인 공개 명세의 존재 여부, 실제 사용 주체의 존재 여부, 기존 용도와의 중복 여부, 그리고 프로토콜 번호가 TCP 포트 같은 다른 메커니즘이 아닌 올바른 수단인지 여부가 포함되었습니다. Standards Action과 IESG Approval을 유지하면서, 비공개 계약과 연관된 전문가 검토(Expert Review) 경로는 제거했습니다. 이 제한된 공개 이름 공간의 경우 검토 가능한 공개 문서가 할당과 함께 요구되어야 한다고 주장했습니다.

이 정책은 목록을 깔끔하게 유지하는 것 이상을 합니다. 전역적으로 보이는 번호는 커널, 패킷 분석기, 보안 장비, 표준, 운영 절차에 들어갈 수 있습니다. 일단 배치되면 이를 회수하거나 재해석하는 일은 레지스트리 항목 자체를 훨씬 넘어서는 조율 비용을 초래할 수 있습니다. 유한한 필드는 각 할당을 오래 지속되는 상호운용성 인프라의 작은 조각으로 만듭니다.

레지스트리가 해결하지 못하는 것

권위적인 온라인 표가 구현체들이 그것을 따르도록 강제할 수는 없습니다. 인용된 RFC들은 소프트웨어가 새로운 할당을 얼마나 빨리 채택했는지, 중간 장비가 낯선 값을 얼마나 일관되게 전달했는지, 사적 관행이 공개 사용과 얼마나 자주 충돌했는지 측정하지 않습니다. 최신 레지스트리는 조율의 원천에서 모호성을 줄일 뿐, 네트워크 가장자리의 지연, 필터링, 경화(ossification)를 없애지는 못합니다.

프로토콜 값은 페이로드에 대한 증명도 아닙니다. 그것은 의도된 상위 프로토콜 해석을 선언할 뿐입니다. 수신자는 지원이 없거나 정책을 적용하거나 디멀티플렉싱 후 잘못된 데이터를 거부할 수 있습니다. 그러한 결과는 8비트 필드가 보장하는 범위 밖에 있습니다.

남는 교훈은 아키텍처적입니다. IPv4의 프로토콜 필드는 스스로를 설명하는 필드가 되지 않고도 생존했습니다. 안정적인 구문이 유지 관리되는 공개 어휘와 짝을 이루었기 때문입니다. 옥텟은 고정된 채로 있었습니다. 그 의미에 대한 권한은 주기적인 문서 스냅샷에서 살아 있는 레지스트리로 옮겨갔고, 이름 공간이 차오르면서 할당 규칙은 더욱 명시적이 되었습니다. 오래된 것은 1981년에 모든 답을 고정한 결과가 아니라, 시스템의 어느 부분이 바뀌도록 허용되는지를 정한 결과였습니다.

출처