Summary

  • RFC 3091 told a multicast provider to send π digits to 314.159.265.359, a string that is not a valid IPv4 multicast address.
  • Its other signature values, TCP/UDP ports 314159 and 220007, also exceed the 16-bit transport port fields; memorable numbers could not make those instructions executable as written.

At first glance, RFC 3091 looks unusually easy to implement. A client lacking local support for π could connect to a server, receive digits, or ask for one by position. A third option would send randomly selected digits to a multicast group; listeners would collect them over time and reconstruct a coherent value. The specification supplies different interaction models, but all three depend on constants that have to pass through the network's real address fields.

The multicast design is the cleanest place to see the gap. RFC 3091 names 314.159.265.359 as its group. IPv4 dotted-decimal notation has four octets, each bounded by 255; RFC 1112 places IPv4 host-group addresses between 224.0.0.0 and 239.255.255.255. This string has five components, and its first component is already too large. It is not merely an unassigned multicast group waiting for an administrator. It cannot denote an IPv4 group address in the first place. A host cannot join the literal group specified by the document.

The problem is not limited to the multicast path. RFC 793 gives TCP source and destination ports 16 bits each; RFC 768 does the same for UDP. A 16-bit unsigned field tops out at 65,535. RFC 3091's required TCP service asks for port 314159, and its optional UDP service repeats that value. Its approximate 22/7 services use 220007. None can be encoded as a TCP or UDP port number. RFC 6335's later division of port numbers into IANA ranges concerns allocation inside the field's representable space; registration cannot make a six-digit value fit into sixteen bits.

That makes RFC 3091 more revealing than a list of π-themed constants. In the TCP version, the server would send an open-ended stream until a client closed the connection. The UDP version instead asks for the nth digit and returns an indexed answer. Multicast removes the request: a provider waits to see whether another provider appears, then broadcasts a random distribution that receivers are meant to assemble over time. The prose describes coherent service behavior at each layer, but the first operational step in each branch is to reach an endpoint the protocol cannot represent.

The document is dated 1 April 2001 and labeled Informational. The IETF Datatracker identifies its publication stream as Independent Submission and explicitly says it is not endorsed by the IETF or part of the IETF standards process. Those facts, the unencodable numbers and the security section's warning that the Internet would imminently collapse without trusted π servers all make the document read as a joke. That is a strong contextual reading, not proof of the author's private intent.

The archival fact is narrower: an RFC-editorial document presented the design in the form of a protocol, but its assigned addresses do not fit the protocols it invokes.

That distinction is important because an RFC number is not itself an implementation result. The publication records what was written and how it was issued. It does not show that a host bound to the specified port, that a multicast group existed, that a deployment repaired the numbers, or that clients assembled digits on a real network. The RFC's references to calculation methods and DNS SRV service discovery add technical texture; they do not repair the field widths. SRV can advertise a port value, but the receiving transport still has to carry that value.

RFC 3091 therefore offers a small lesson in Internet engineering history: protocol prose can be internally fluent while failing at the boundary between names and wire representation. A port number may look like an elegant reference to π, and an address may resemble a sequence of digits, yet neither becomes a network identifier by resemblance. Before debating service discovery, load balancing or receiver convergence, one must first ask whether the bits on the wire can encode the destination at all.

Sources