요약

  • RFC 3091은 멀티캐스트 공급자에게 π 자릿수를314.159.265.359로 보내라고 했는데, 이 문자열은 유효한 IPv4 멀티캐스트 주소가 아닙니다.
  • 다른 대표 값들인 TCP/UDP 포트314159와220007역시 16비트 전송 포트 필드를 초과합니다; 기억하기 쉬운 숫자만으로는 그 지시들이 명세 그대로 실행 가능해지지 않습니다.

언뜻 보면 RFC 3091은 특이할 만큼 구현이 쉬워 보입니다. π를 로컬에서 지원하지 않는 클라이언트는 서버에 접속해 자릿수를 받거나, 원하는 자리를 지정해 하나를 요청할 수 있습니다. 세 번째 방식은 무작위로 뽑은 자릿수를 멀티캐스트 그룹으로 보내고, 수신자들이 시간이 지나며 이를 모아 하나의 일관된 값으로 재구성하게 됩니다. 명세는 서로 다른 상호작용 모델을 제시하지만, 세 방식 모두 네트워크의 실제 주소 필드를 통과해야 하는 상수에 의존합니다.

멀티캐스트 설계에서 이 간극이 가장 선명하게 드러납니다. RFC 3091은314.159.265.359를 자신의 그룹으로 지목합니다. IPv4 점분리 십진 표기는 옥텟 넷으로 구성되며 각 옥텟의 상한은 255이고, RFC 1112는 IPv4 호스트-그룹 주소를224.0.0.0에서239.255.255.255사이로 정합니다. 이 문자열은 다섯 개 구성요소를 갖고 첫 구성요소조차 이미 한도를 넘습니다. 이는 관리자의 할당을 기다리는 미배정 멀티캐스트 그룹 정도가 아니라, 애초에 IPv4 그룹 주소를 나타낼 수 없는 값입니다. 호스트는 문서가 지정한 그 그룹에 문자 그대로 참여할 수 없습니다.

문제는 멀티캐스트 경로에만 국한되지 않습니다. RFC 793은 TCP 출발지·목적지 포트에 각각 16비트를 부여했고, RFC 768은 UDP에도 같은 폭을 줍니다. 16비트 부호 없는 필드의 최댓값은 65,535입니다. RFC 3091의 필수 TCP 서비스는 포트 314159를 요구하고, 선택적 UDP 서비스도 같은 값을 반복합니다. 근사값22/7서비스들은 220007을 사용합니다. 어느 것도 TCP 또는 UDP 포트 번호로 인코딩될 수 없습니다. RFC 6335가 이후 포트 번호를 IANA 범위로 나눈 것은 필드가 표현할 수 있는 공간 안에서의 할당 문제를 다룹니다; 등록 절차가 여섯 자리 값을 열여섯 비트에 맞춰 넣어 줄 수는 없습니다.

그래서 RFC 3091은 π 테마 상수의 나열 이상으로 의미심장한 사례가 됩니다. TCP 버전에서 서버는 클라이언트가 접속을 끊을 때까지 끝없는 스트림을 보냅니다. UDP 버전은 대신 n번째 자릿수를 요청받아 인덱스된 답을 돌려줍니다. 멀티캐스트는 요청 자체를 없애 버립니다: 공급자가 다른 공급자가 나타나는지 기다렸다가, 수신자들이 시간이 지나며 조립하도록 의도된 무작위 자릿수 분포를 브로드캐스트합니다. 산문은 각 계층에서 일관된 서비스 동작을 묘사하지만, 각 분기의 첫 운영 단계는 곧바로 그 프로토콜이 표현할 수 없는 종단점에 도달하는 일입니다.

이 문서는 2001년 4월 1일자로, Informational로 표기되어 있습니다. IETF Datatracker는 그 출판 스트림을 Independent Submission으로 식별하며, IETF가 보증하지 않고 IETF 표준 절차의 일부가 아니라고 명시합니다. 이 사실들, 인코딩할 수 없는 숫자들, 그리고 신뢰할 수 있는 π 서버가 없으면 인터넷이 곧 무너질 것이라는 보안 절의 경고가 모두 이 문서를 농담으로 읽게 만듭니다. 그것은 강력한 맥락적 해석이며, 저자의 사적 의도에 대한 증명은 아닙니다. 기록상 사실은 더 좁습니다: RFC 편집상의 문서가 프로토콜의 형식으로 그 설계를 제시했지만, 그에 할당된 주소들은 그것이 소환하는 프로토콜들에 맞지 않았다는 것입니다.

이 구분이 중요한 이유는 RFC 번호 자체가 구현 결과가 아니기 때문입니다. 출판 기록은 무엇이 쓰였고 어떻게 발행되었는지를 담습니다. 어떤 호스트가 지정된 포트를 바인딩했는지, 멀티캐스트 그룹이 존재했는지, 어떤 배포가 숫자를 수선했는지, 클라이언트가 실제 네트워크에서 자릿수를 조립했는지는 보여 주지 않습니다. RFC가 계산 방법과 DNS SRV 서비스 디스커버리를 인용하는 것은 기술적 질감을 더할 뿐; 필드 폭은 수선하지 못합니다. SRV는 포트 값을 광고할 수 있지만, 그 값을 실어 나르는 것은 수신 측 전송 계층입니다.

따라서 RFC 3091은 인터넷 공학사의 작은 교훈을 줍니다: 프로토콜 산문은 이름과 와이어 표현 사이의 경계에서 실패하는 한, 그 자체로 문법적으로 유창할 수 있습니다. 포트 번호는 π의 우아한 참조처럼 보일 수 있고, 주소는 자릿수의 나열처럼 보일 수 있지만, 어느 쪽도 외견만으로 네트워크 식별자가 되지는 않습니다. 서비스 디스커버리, 로드 밸런싱, 수신자 수렴을 논하기 전에 먼저 물어야 합니다: 와이어의 비트가 애초에 그 목적지를 인코딩할 수 있는가.

출처