Summary

  • RFC 6709 made “routine” a test of protocol behavior and compatibility, not a count of lines in a patch. Existing implementations had to be able to ignore the extension safely; if the base protocol, its assumptions, or deployed software needed to change, the work could be major even when the wire format barely moved.
  • Routine status did not automatically remove the need for expert review. RFC 6709 says low-review processes should be limited and that routine extensions can still benefit from experts; RFC 4775 separately explains why new RADIUS attributes need architectural review.

The word that hid a second decision

A standards discussion can ask two different questions in one breath. What will this extension do to the protocol and the systems already speaking it? And what review should the proposal receive before others rely on it? The word “routine” is tempting because it appears to answer both. RFC 6709 shows why it cannot.

The Internet Architecture Board published RFC 6709 as an Informational document in September 2012. It was meant to help designers of both base protocols and extensions reason about architecture. The document says that extensions can make protocols easier to evolve, but can also create interoperability, operational, and security problems. Its organizing distinction—routine versus major—connects the likely effect of a proposal to the amount of scrutiny it may need. It is design guidance, not an Internet Standard or a universal approval rule.

The RFC places itself in a longer debate. It points back to RFC 1263, the 1991 “TCP Extensions Considered Harmful” memo, as an earlier warning about extension costs. That memo is already its own historical argument: RFC 6709 does not reopen the TCP version-boundary dispute. It says that generic design considerations for extensions had not previously been documented together. RFC 4775, published in 2006 as BCP 125, supplied procedural guidance for extending IETF protocols. RFC 6709 set out to describe the architectural test that should inform such work.

Major was about consequences, not packet size

RFC 6709 gives designers eight kinds of impact to examine. Would an implementation of the underlying protocol need to change? Does the proposal alter an architectural assumption, such as requiring session state in a protocol designed to be stateless? Does it introduce a new use or scale that could increase traffic, packet sizes, or processing load beyond what existing systems can handle? Does it fit the extension model the base protocol actually defined? Does it change syntax, couple extensions across protocols, alter the security model, or affect performance in existing deployments?

Any of those can push work into the major category. A new message type or transport may require updates even for deployed implementations that do not want the new feature. A change can leave the bytes on the wire untouched yet introduce a scale that strains old algorithms. A base protocol that does not define safe handling for unknown extensions can make an apparently minor proposal major by default. These are RFC 6709’s design tests; they are not a numeric score or a finding about any current product.

The underlying question is who must change, and what happens to everyone who does not. The size of an edit is a poor proxy. One short field can change how a receiver parses a message; a larger vendor-defined value may remain invisible to the base protocol. In RFC 6709’s terms, the first might be major and the second might be routine, but only if the actual compatibility conditions hold.

Routine had a strict edge

An extension could be considered routine if it did not meet the major criteria and remained opaque to the base protocol. It should not substantially change the pattern of messages and responses. The base specification and already deployed implementations should not need changes, except for systems that choose to use the extension. Existing implementations should not otherwise be affected; typically, they need to ignore the extension without ill effects.

RFC 6709 gives DHCP vendor-specific options, RADIUS Vendor-Specific Attributes, enterprise object identifiers for management information modules, and vendor MIME types as examples. The key is not that these are small additions. The key is that the extension can fit the space the base protocol set aside without changing what non-participants must do.

The same passage blocks a common misreading. RFC 6709 says routine extension mechanisms with minimal or no review—such as First Come First Served allocation—should be used sparingly. It limits them to cases unlikely to cause interoperability, security, or operational exposures. It then adds that even a routine extension may benefit from experts: an opaque DHCP value can still be needlessly hard for clients and servers to process if its data is unstructured.

RADIUS shows why the two questions stay separate

The companion RFC 4775 makes the distinction concrete. It treats routine IANA parameter assignments under a clear existing specification as a narrow procedural case; anything beyond that requires explicit protocol review by IETF experts. It also says proposals for new RADIUS attributes should be discussed with people who understand the protocol’s architecture and existing use, because adding attributes without that discussion creates interoperability or functionality risk.

RFC 6709 itself lists RADIUS Vendor-Specific Attributes as an example of routine extensibility. That does not contradict RFC 4775. The labels answer different questions. “Routine” asks whether the extension fits the architecture and can be ignored safely by systems that do not use it. RFC 4775 asks what procedure and expertise should govern a proposal. RFC 6709 explicitly leaves room for expert review even after an extension passes its routine test.

This separation matters because registration or publication alone does not establish that an extension is harmless, implemented, or adopted. A review path can identify issues before a proposal moves forward. It cannot stand in for tests of the actual implementation or evidence that operators deployed it.

Three receipts, not one label

A useful review record therefore keeps three questions visible. First, what does the extension change in the base protocol, its assumptions, message behavior, or resource demands? Second, can existing implementations that do not opt in safely ignore it? Third, what level of protocol, security, and operational review is justified by the answer to the first two?

If the proposal needs existing software to change, alters message sequencing, adds state, crosses protocol boundaries, or shifts a security assumption, treating it as routine requires a stronger explanation. If the change is truly opaque and non-participants remain unaffected, that supports a routine classification—but does not forbid expert review. Test cases must still show how implementations behave, and a registered value is not evidence that a deployed path carries it correctly.

RFC 6709 also warns against designing more extensibility than a protocol reasonably needs at inception. It notes that future uses may be unknown, while saying that this does not require an initial design to anticipate every possible demand. That is compatible with a modest rule: preserve a safe place for change, but do not pretend that every later use will fit it.

What the record does—and does not—show

RFC 6709 documents an IAB approach to extension design, not an empirical census of implementations. RFC 4775 records procedures, not proof that those procedures were followed for every proposal. The sources establish the tests and warnings the documents stated. They do not show how many extensions were deployed, whether a named network adopted one, or whether a given extension caused an incident.

Heng Lu’s Note 64 offers a separate editorial lens: define only the common rules needed for interoperability, leave later choices with participants where possible, and treat change as operationally real through implementation and adoption. It is a later BTW interpretation, not a statement of the IAB’s intent. Under that lens, “routine” describes a compatibility boundary. It does not turn publication, a registry entry, or a review outcome into proof of adoption.

The historical value of RFC 6709 is the question it makes harder to evade: can old systems safely ignore this extension, or are they being asked to change? Once that answer is clear, the review process can be chosen on purpose. Routine is not shorthand for harmless, and major is not a judgment about how many lines were written.

Sources