Summary

  • RFC 3936 divided RSVP allocation space among Standards Action, Expert Review and Vendor Private use, but every Class-Num remained inside a pre-existing unknown-object behavior band.
  • A private value could therefore make an old node reject a whole message, drop only the unfamiliar object or forward that object unchanged. Allocation authority and execution behavior were separate.

The old router did not need to know the object

Imagine an RSVP message reaching a node built before one of its objects existed. The node cannot parse the new object's meaning. It can still act on it.

That result follows from RFC 2205, the 1997 RSVP specification. An object header carries an eight-bit Class-Num and an eight-bit C-Type. Section 3.10 assigns behavior to the Class-Num pattern. If the class looks like 0bbbbbbb, the node rejects the entire message and returns an Unknown Object Class error. If it looks like 10bbbbbb, the node ignores the object, neither forwarding it nor sending an error. If it looks like 11bbbbbb, the node ignores the object's meaning but forwards it unexamined and unmodified in messages resulting from the one it received.

The RFC Editor record for RFC 2205 establishes the document's status and history. The operational distinction lives in the wire field. A node does not consult the political history of a code point before acting. It reads the leading pattern.

That is the engineering constraint behind RFC 3936, published in October 2004 as BCP 96. The memo updated RSVP and the traffic-engineering extensions in RFC 3209. It wanted extensions to receive adequate review without making experimentation impossible. Yet it could not allocate all new classes from one undifferentiated pool. The pool was already an execution map.

Nine allocation slices preserved three compatibility corridors

RFC 3936 divided each Class-Num behavior band again. In the rejecting band, values 0–119 required Standards Action, 120–123 used Expert Review, and 124–127 were Vendor Private. In the discard-object band, the corresponding slices were 128–183, 184–187 and 188–191. In the forward-unknown band, they were 192–247, 248–251 and 252–255.

The current IANA RSVP Parameters registry still displays those nine slices. It is tempting to read the table as administrative housekeeping. It is more precise to see a matrix. One axis decides how a new use is authorized. The other decides what old code does when it cannot understand that use.

Standards Action was intended for widely accepted extensions whose consequences were understood. Expert Review values were normally for experiments and had to be requested through an Experimental RFC that documented their use and processing. Vendor Private values were not individually registered. The RFC 3936 information page identifies the BCP and the RFCs it updates; its errata page is the place to verify corrections rather than silently rewriting the original rule.

None of those documentary paths changes the leading-bit behavior. A private class chosen from 124–127 still inhabits the reject-message corridor. A private class from 188–191 is discarded at an old node while the rest of the message can continue. A private class from 252–255 can be carried through that node to a downstream implementation that recognizes it. “Private” answers who coordinates the number. It does not answer what the network does with the octet.

Private reuse needed a public discriminator

RFC 3936 allowed different enterprises, vendors and standards organizations to reuse the same private code point. It avoided collision by requiring the first four-octet word of the relevant data field to contain an SMI Private Enterprise Number. Those identifiers come from the public IANA Private Enterprise Numbers registry.

This was an economical form of namespace nesting. IANA did not need to list every proprietary object. A receiving implementation could see the private Class-Num, then inspect the enterprise word if it knew the private format. Two companies could occupy the same private numeric slot without their objects becoming indistinguishable.

The boundary matters. An enterprise number is not a signature. It does not authenticate the sender, prove ownership of a device, certify the payload or make two formats interoperable. RFC 3936 explicitly says that an implementation which does not recognize the enterprise code still treats the object and enclosing message according to the Class-Num rule. The outer compatibility behavior remains public even when the inner meaning is proprietary.

RFC 2207, which defined RSVP extensions for IPsec flows, is one source for the virtual-destination-port space also noted by RFC 3936. The example reinforces the architecture: each namespace needs its own assignment and processing rules. “RSVP extension” is not a single global permission.

Unknown class and unknown subtype were different failures

The high-bit story applies when the object class itself is unknown. RFC 2205 treats an unknown C-Type inside a known Class-Num differently. The implementation knows the class but not the subtype, and generally rejects the entire message with an error. A familiar envelope does not make an unfamiliar variant safe to skip.

RFC 3936 preserved that scoping. C-Types belong to one Class Number. A document defining a new class has to state how later C-Types will be assigned. For legacy classes, the default remained Standards Action unless a Standards Track or Best Current Practice RFC replaced it.

Route sub-objects are another separate namespace. RFC 3209's official record describes RSVP-TE for LSP tunnels, while RFC 3473 shows later GMPLS signaling extensions. RFC 3936 divided EXPLICIT_ROUTE and RECORD_ROUTE sub-object types into standards, expert and private ranges and again required an enterprise word for private formats. But a sub-object's type field is not a Class-Num; it does not inherit the three unknown-class behaviors merely because both live in RSVP.

The category of the document constrained changes to code

RFC 3936 also linked procedure changes back to the allocation lane. A change in processing for an entity from a Standards Action range had to appear in a Standards Track RFC. A corresponding change for an Expert Review entity had to appear in an Experimental RFC. The registry decision was therefore not the end of governance. Changing what implementations were expected to do required documentation with a matching level of review.

The policy language came from the contemporary guidance in RFC 2434. RFC 8126 later replaced that general IANA guidance. The later document can explain today's vocabulary, but it did not retroactively design the 2004 RSVP matrix.

RFC 3936 hoped that better review would make RSVP changes more architecturally sound and improve security. That is rationale, not a measured result. The IANA table proves which ranges and recorded assignments exist. It does not reveal which vendors implemented them, which private values cross production networks, whether old nodes followed the rules correctly, or whether any particular extension succeeded.

This is where Heng Lu's distinction between a minimum initial specification and later voluntary adoption and the primacy of running code sharpens the history. Registration, implementation and operational use are separate claims. RFC 3936 made the first claim govern the compatibility corridor. Only packet traces, code, interoperability results and deployment records could establish the rest.

The durable lesson is not simply that IANA managed a scarce byte. The byte already carried a decision for code that had never heard of the extension. RFC 3936 placed public standards, bounded experiments and proprietary work inside that inherited machine behavior. The code point could be private. Its effect on an unknown router never was.