Summary

  • Fred Baker edited RFC 1812 as a procurement specification and implementer guide, while the document says its own list is incomplete and relies on the underlying protocol standards.
  • Later updates to directed-broadcast and Source Quench behavior show why a standards baseline must be read alongside newer specifications and evidence from the product and network actually in use.

A router specification can look like a checklist: support this protocol, meet that requirement, pass procurement. RFC 1812 makes the checklist harder to use—and more useful. Its preface says the editor had been asked to make the document serve procurement and implementation. The same document warns that its list is incomplete by itself. The full requirements for an Internet router sit mainly in the individual protocol specifications, together with RFC 1812’s corrections and additions.

The distinction matters because “standard” can be mistaken for a product certificate. RFC 1812 does not certify a router model, software release, configuration or live route. It sets a normative target and points readers to the other documents that complete it. A buyer can cite it in a contract; an operator still needs evidence that the particular system behaves as the contract requires.

Fred Baker’s role is unusually clear on the title page: “F. Baker, Editor.” Published in June 1995 as a Standards Track document, RFC 1812 replaced RFC 1716 and RFC 1009. The preface gives Baker credit for updating the work, but explicitly says he relied heavily on expert contributors and that credit belonged to them. It also identifies Philip Almquist, the working-group chair and original editor and author, as responsible for much of the document’s content and form, and Frank Kastenholz as its previous editor. This is an editorial chain, not a claim of sole invention.

The document’s own account of scope resists checklist thinking. It gathers requirements, recommendations and options; corrects errors in referenced protocol specifications; and adds discussion for implementers. It says a simple list would be dangerous because not every feature has equal importance, optional behavior exists, and a feature can matter greatly for one router use but be irrelevant to another. It even notes that restricted-context products may have valid reasons to follow different specifications. The document’s aim is broad interoperability, not the fiction that every router is interchangeable.

Two later updates make the boundary concrete. RFC 2644, written by Daniel Senie and published in 1999, changed RFC 1812’s directed-broadcast default. The earlier requirement allowed receipt and forwarding by default; the update required both to be blocked unless an operator explicitly enabled them. The reason was practical: directed broadcasts were being abused as amplifiers in Smurf denial-of-service attacks. That update changed a configuration default, not the definition of every router or the full security posture of an operator.

RFC 6633, published in 2012 by Fernando Gont, addressed ICMP Source Quench. RFC 1812 had already deprecated routers’ generation of those messages. RFC 6633 went further on the receive side, requiring routers to ignore them and updating host guidance as well. Its rationale included their poor congestion-control behavior, filtering that made them unreliable, and the fact that popular TCP implementations had already stopped supporting them. The later document therefore did not reverse RFC 1812; it completed and clarified a change whose operational context had evolved.

Baker’s broader IETF record helps explain why the editor’s role matters without turning him into the sole author. An IETF memorial draft records that he chaired the IETF from 1996 to 2001 and co-authored or edited more than 60 RFCs. The RFC 1812 preface is more specific than a résumé: it shows how a standards document depends on earlier editors, a working group and technical contributors, while still placing responsibility for editorial errors on its named editor.

The useful procurement question is not simply whether a vendor says “RFC 1812 compliant.” It is which requirements apply to the intended use, which referenced specifications and updates are included, which features are optional, and what the selected model and software version actually do under the planned configuration. A test plan can then separate control-plane claims from forwarding behavior, defaults from explicitly enabled features, and a paper conformance statement from observed packets. That is analysis, not a claim that any specific device has been tested here.

Heng Lu’s Note 65, “Running-Code Primacy,” offers an editorial lens for keeping documented intention distinct from deployed behavior. It is not evidence about Baker or RFC 1812. Read through that lens, RFC 1812 is neither a substitute for testing nor a disposable checklist: it is a map of requirements whose references, options and updates have to be followed to the operating system that is actually carrying traffic.

Sources