RFC 3115: When Running Code Overruled the Printed Numbers

Summary

RFC 3025 printed 37 for the critical vendor extension and 133 for the normal one. IANA assigned 38 and 134. RFC 3115 obsoleted the February 2001 document in April because current implementations followed IANA.
The discrepancy changed more than a label. In Mobile IP, an unknown type below 128 made the receiver silently discard the whole message; an unknown type at or above 128 could be skipped while the rest continued.

One octet chose the fate of the message

Imagine a Mobile IP registration request reaching a foreign agent with an extension the receiver has never seen. If the extension's first octet falls in one half of the number space, the agent stops. It discards the datagram, does no more processing and sends no error to the originator. If the octet falls in the other half, the agent reads the length, steps around the unknown data and continues.

The difference between those two futures was encoded before the private payload began. Mobile IP did not need to understand the vendor's data to decide whether ignorance was fatal. The outer type already declared whether the message remained meaningful without it.

In February 2001, RFC 3025 created two containers for organization-specific Mobile IP data. It printed type 37 for the Critical Vendor/Organization-Specific Extension, CVSE, and type 133 for the Normal Vendor/Organization-Specific Extension, NVSE. IANA's repository recorded 38 and 134 instead. Two months later, RFC 3115 replaced the document and opened with an RFC Editor note listing the disagreement.

The note did not resolve the conflict by treating the published RFC as automatically supreme. It said RFC 3025 was being obsoleted because current implementations followed the IANA assignments. The new text used 38 and 134.

That sentence is a small monument to Running-Code Primacy. There was a document, a registry and a wire population. The document was recent and standards-track. The registry was the allocation authority. The implementations supplied the operational fact. When the three stopped agreeing, the replacement specification aligned the text with the values machines were already speaking.

The source does not name those implementations or count them. It does not prove that every product agreed, or that the mismatch caused an outage. Its claim is narrower and still remarkable: operational behavior was sufficiently established that the standards record moved to match it.

Critical and normal were compatibility contracts

RFC 2002 had divided Mobile IP extensions into two behavioral ranges. An unrecognized extension numbered 0 through 127 required silent discard of the containing message. An unrecognized extension numbered 128 through 255 was ignored, while all remaining extensions and message data still had to be processed. The length field told the parser how far to jump.

RFC 3115 deliberately placed CVSE at 38 and NVSE at 134. The names therefore described receiver behavior, not editorial importance. A critical extension asserted that a receiver unable to understand it could not safely act on the rest of the message. A normal extension asserted that the private addition could be omitted from interpretation without invalidating everything else.

This is why the 37/38 and 133/134 correction cannot be dismissed as clerical hygiene. In both versions, the critical value remained in the non-skippable half and the normal value remained in the skippable half, so the broad policy did not reverse. But a receiver recognizing 38 would treat 37 as some other unknown critical type; a sender emitting 37 would not meet an implementation waiting for 38. The same was true of 133 and 134 in the skippable range, where failure could be quieter: the receiver could bypass a private feature and continue with a message that looked otherwise valid.

Silent discard was itself carefully defined. The receiver stopped without telling the sender. It should, however, be capable of logging the error, including the discarded datagram, and count the event. On the network, absence was the protocol response. Inside the machine, evidence was still expected.

That split matters operationally. A sender observing no reply cannot infer which hop discarded the message, whether the outer type was unknown, whether an authenticator failed, whether a reply was lost or whether a different validity rule fired. The event counter and packet record belong to the receiver that made the decision. Without them, a criticality failure becomes indistinguishable from transport silence.

Recognition happened twice

RFC 3115 contained a second, subtler decision. A receiver could recognize the outer CVSE type 38 and still fail to understand the enterprise number or the vendor-controlled subtype inside it. That was no longer the same failure as not recognizing type 38 at all.

For a request carrying a recognized CVSE container with an unsupported Vendor/Org-ID or Vendor-CVSE-Type, the receiving Mobile IP entity had to send an appropriate denial. For a reply, a transit entity had to produce a rejection toward the next participant; a terminal recipient treated the reply as rejected. The RFC assigned four codes so the foreign agent and home agent could distinguish where the uninterpretable critical data had come from.

By contrast, when a receiver recognized the NVSE container but did not support its vendor or inner subtype, it skipped that extension. Processing continued.

The distinction created two parsing boundaries. Outer-type recognition determined whether the receiver even knew how to locate the container's fields. Inner-namespace recognition determined whether it understood the private semantic. At the outer boundary, an unknown critical type disappeared into silent discard. At the inner boundary, a known critical container produced an explicit protocol denial.

Logs that record only “unknown vendor extension” erase this architecture. A useful record needs the outer type, whether the base parser recognized it, the enterprise number, the vendor subtype, the message direction, the role of the interpreting node, the chosen disposition and any emitted denial code. Only then can an operator tell a parser-version mismatch from a private-capability mismatch.

The registry delegated a namespace, not the outcome

Both containers carried a four-octet Vendor/Org-ID. The high octet was zero; the lower three held the organization's SMI Network Management Private Enterprise Code. Inside that namespace, the vendor or organization administered a two-octet subtype and its value.

The architecture divided control among several custodians. IANA assigned the outer Mobile IP types and denial codes. The private-enterprise registry anchored the organization identifier. The organization defined its subtypes. A sender chose which instances to place in a message. A receiver decided which private semantics it implemented. Mobile IP authenticators protected the enclosing exchange where required. Local policy still decided whether the requested registration or feature was acceptable.

No identifier carried all those decisions. An assigned enterprise number proved namespace custody, not that a packet genuinely came from the named organization. Message authentication could protect origin and integrity under a mobility security association, but it did not teach the receiver what an unknown vendor value meant. Recognition did not equal authorization. A registration acceptance did not prove that a user-visible service worked.

RFC 3115 allowed multiple CVSE and NVSE instances after the fixed portion of a Mobile IP message. Their ordering should not be changed by intermediate nodes. That made order part of the evidence even though the RFC did not claim every private format depended on it. A normalized log that sorts extensions for convenience can lose the exact message an authenticator covered and the sequence downstream parsers saw.

The document's security section said it assumed Mobile IP messages were authenticated using the base protocol and imposed no new security requirements. That is an assumption in the specification, not evidence that any deployment authenticated every relevant path or that private values were harmless. A sound audit preserves the authenticator result, security association and covered bytes separately from vendor-subtype support and policy outcome.

Four errors mapped a three-party path

Mobile IP registration involved a mobile node, a foreign agent and a home agent. RFC 3115's four new rejection codes made that topology visible.

Codes 100 and 101 belonged to denial by the foreign agent. The first described an unsupported vendor ID or CVSE subtype sent from the mobile node toward the foreign agent. The second described such data arriving from the home agent. Codes 140 and 141 belonged to denial by the home agent, distinguishing CVSE data sent by the mobile node from data sent by the foreign agent.

These codes were not generic proof that “the vendor extension failed.” They identified the interpreting role and one direction of provenance. They still did not reveal the private value's intended business meaning, show that the denial reached the mobile node, or prove the eventual subscriber outcome. A transit node could convert an incomprehensible reply into a new rejection; a terminal node could treat the reply as rejected locally. The wire result depended on where incomprehension occurred.

This is the kind of detail that vanishes when a distributed protocol is reported as a single server response. A trustworthy event chain keeps the original request, every extension in order, each agent's recognition result, any transformed reply, the final registration state and the later traffic path. The denial code is one link, not the narrative.

The online registry was becoming the live source

RFC 3115 arrived during a broader transition in how Internet parameters were maintained. RFC 1700, published in 1994, had been a static Assigned Numbers snapshot. RFC 3232 later made the institutional change explicit: online IANA databases had replaced the serial RFC snapshots, and RFC 1700 was incomplete and in some cases wrong.

The 3115 correction preceded RFC 3232 by less than a year, but it already exhibits the new operating reality. A registry could move at allocation speed while a published document froze. Implementers needed the live allocation record, not only the document that described the packet shape. The cost of disagreement appeared directly on the wire.

That did not make prose disposable. The registry knew that 38 meant CVSE and 134 meant NVSE; it did not by itself define the container fields, the inner namespace, transit behavior, error paths or authentication assumptions. Conversely, the RFC could explain all of those and still print the wrong type. Interoperability required the join between semantics and allocation.

The current IANA Mobile IPv4 Numbers registry preserves that join. It lists 38 and 134 with RFC 3115 as their reference, as well as the four rejection codes. This is current-state evidence. It does not reconstruct every edit or tell us precisely when each implementation changed. Historical analysis still needs the frozen RFCs and their explicit correction note.

Later uses prove specificity, not prevalence

Subsequent RFCs show what organizations placed inside the generic containers. RFC 4332 specified Cisco extensions for home-network prefix, gateway, DNS, DHCP information and a configuration URL. RFC 4784 specified three Verizon Wireless Mobile IP extensions using CVSE type 38 and enterprise number 12951 as part of a dynamic key-update procedure for cdma2000 networks.

Those documents prove defined use cases. They do not provide installation counts, packet traces, interoperability results or commercial outcomes. A requirement in a specification is not proof that a particular foreign agent executed it. A registered enterprise number is not a deployment census.

RFC 5612 later allocated enterprise number 32473 for documentation and examples. That safeguard illuminates the same governance problem from another angle. Even sample packets need an identifier that will not be mistaken for a real organization's private namespace. Examples can escape into code, captures and tests; namespace discipline prevents fictional ownership from colliding with operational ownership.

RFC 6709 later generalized the hazards of extension mechanisms. Private extension spaces can enable local innovation, but minimal review, uncertain criticality and weak behavior for unknown values can expose interoperability, security and operations. RFC 3115 is an early concrete specimen: its two containers explicitly priced ignorance, one as message failure and the other as feature loss.

What the replacement did—and did not—prove

It is tempting to turn RFC 3115 into a fable in which running code always defeats documentation. The evidence is more disciplined. The new RFC did not say “ignore standards.” It repaired the standards record so the allocation authority, packet syntax and existing implementations agreed. It preserved the reviewable semantics and made the deployed number choice normative.

Nor did the replacement certify every implementation. The phrase “current implementations” lacks names, versions and measurements. It should be quoted at its proper strength: the RFC Editor reported enough implementation alignment with IANA to justify obsoleting RFC 3025. Claims about market share, outages or universal adoption would require evidence the selected sources do not contain.

The durable lesson is therefore about evidence custody. A published RFC can be wrong at one field. A live registry can carry the right number without the complete behavior. Running code can reveal the interoperable value while still containing bugs elsewhere. A packet capture can prove emission but not acceptance. A receiver log can prove a parsing decision but not successful service.

For RFC 3115, the decisive chain is visible: RFC 3025 printed 37 and 133; IANA held 38 and 134; implementations followed IANA; RFC 3115 replaced the document. The correction worked because each layer could be named. The registry and the RFC disagreed. Running code did not erase either record. It showed which record the wire had already chosen.

The Registry and the RFC Disagreed. Running Code Chose the Registry: RFC 3115

Why it matters

Summary

One octet chose the fate of the message

Critical and normal were compatibility contracts

Recognition happened twice

The registry delegated a namespace, not the outcome

Four errors mapped a three-party path

The online registry was becoming the live source

Later uses prove specificity, not prevalence

What the replacement did—and did not—prove

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing