Кратко

  • RFC 3091 велел поставщику multicast отправлять цифры π группе 314.159.265.359, но это не допустимый адрес multicast IPv4.
  • TCP- и UDP-порты 314159 и 220007 также превышали 16-битное поле транспорта: в указанном виде эти числа нельзя было поместить в пакет.

Если начать с назначения сервиса, замысел кажется простым. Рабочая станция, не умеющая вычислять π локально, подключается к серверу и получает цифры, запрашивает одну по номеру либо слушает multicast-передачу. В последнем варианте поставщик рассылает случайную последовательность цифр, а получатели со временем собирают согласованное значение. В RFC описаны три способа взаимодействия, однако каждый начинается с условия попроще: адрес и порт должны помещаться в поля, которые сеть действительно переносит.

Именно multicast-путь яснее всего показывает расхождение. RFC 3091 называет адресом группы 314.159.265.359. В точечной десятичной записи IPv4 — четыре октета от 0 до 255; RFC 1112 задаёт для групп узлов IPv4 диапазон от 224.0.0.0 до 239.255.255.255. В строке RFC пять компонентов, а первый уже больше 255. Это не допустимая, но ещё не назначенная группа, которую мог бы зарегистрировать администратор. Строка вообще не обозначает IPv4-адрес, и узел не может вступить в группу, буквально указанную в документе.

У портов та же проблема. RFC 793 определяет TCP-поля портов источника и назначения шириной 16 бит; в RFC 768 для UDP ширина такая же. Максимальное беззнаковое значение — 65 535. Тем не менее обязательная TCP-служба в RFC 3091 должна слушать порт 314159, и необязательная служба UDP использует его же. Для приближённых служб 22/7 указан порт 220007. Ни одно число не кодируется как номер TCP- или UDP-порта. Процедуры IANA в RFC 6335 распределяют номера в пределах пространства, которое представляют поля; регистрация не расширяет само поле.

Речь не просто о забавной игре с числами. TCP-вариант должен непрерывно передавать цифры до закрытия соединения клиентом. Вариант UDP позволяет запросить n-ю цифру и получить ответ с её индексом. Multicast отменяет запрос: поставщик ждёт тридцать секунд, не обнаруживая другого поставщика, после чего передаёт случайную последовательность, из которой клиенты должны со временем собрать единое значение. RFC описывает поток, выборочный запрос и распределённый сбор, но первый шаг в любом из этих режимов — добраться до адресата, которого транспортный или сетевой протокол не способен представить.

Документ датирован 1 апреля 2001 года и имеет категорию Informational. IETF Datatracker относит его к потоку Independent Submission и прямо указывает, что IETF его не одобряла и он не имеет формального статуса в процессе стандартизации IETF. Дата, некодируемые числа и предупреждение о скором крахе Интернета без доверенного сервера PIgen убедительно наводят на мысль о шутке. Но это контекстное прочтение, а не независимое доказательство личного намерения автора. Более узкий архивный факт таков: RFC-подобная публикация описала сервисы с адресами, которые нельзя выразить протоколами, к которым она обращается.

Номер RFC сам по себе не подтверждает наличие реализации. Запись о публикации показывает, что именно было написано и по какому редакционному потоку документ вышел; она не доказывает, что какой-либо узел слушал указанный порт, что существовала группа multicast, что при развёртывании кто-то исправил константы или что клиенты собирали π в настоящей сети. Ссылки на методы вычисления и обнаружение службы через DNS SRV добавляют технические детали, но не решают проблему разрядности. SRV может объявить порт; транспорт всё равно должен суметь его передать.

RFC 3091 оставляет конкретный урок истории интернет-инженерии: текст спецификации может быть гладким и логичным, но провалиться на переходе от имени к представлению на проводе. Число, напоминающее π, и строка, похожая на запись цифр, от этого не становятся сетевыми идентификаторами. Прежде чем обсуждать обнаружение сервисов, балансировку нагрузки или согласование данных у получателей, нужно проверить, хватает ли битов для кодирования адресата.

Источники