Summary

  • RFC 9900 de-assigns TCP and UDP ports 831, 832 and 833 while retaining their historic NETCONF service names; it changes coordinated registry state, not every endpoint's local state.
  • Retirement and future reuse need scoped evidence across service-name databases, configurations, listeners, middleboxes and packet content, because a bare port number neither proves a protocol nor proves its absence.

The registry entry was already correct. Three port-number fields were empty, each historic service name remained visible, and the release note pointed to RFC 9900. The cleanup ticket therefore looked finished.

Then the estate inventory disagreed in three different ways. An old appliance image still mapped one name to its former number. A firewall object still allowed the number toward a management segment. A socket scan found a listener, but no packet capture had established what protocol—if any—it spoke. None of those observations invalidated the registry action. They exposed three local questions the registry had never claimed to answer.

RFC 9900 performs a narrow act. It de-assigns TCP and UDP port 831 from netconf-beep, port 832 from netconfsoaphttp, and port 833 from netconfsoapbeep. The related RFC 4744 and RFC 4743 specifications are Historic. RFC 9900 says the protocols are not deployed and that there are no known implementations or deployments relying on the released numbers.

The wording matters. “No known” records the result of an inquiry with a bounded observation surface. It is not a mathematical proof about every private network, embedded image, disconnected lab, copied template or unreported implementation. RFC 9900 itself preserves that boundary by telling operators to reassess and update any existing configurations that associate the released numbers with netconf-beep or netconfsoaphttp.

The standard also keeps the service names. Only the port numbers are de-assigned. This is not clerical residue. RFC 6335 makes the service name the unique symbolic key and recommends keeping it after associated port numbers are de-assigned. IANA records historic use so a later reader can distinguish “never assigned” from “formerly coordinated here.”

That produces two valid but different statements. The global registry can say that 831 is no longer assigned to NETCONF over BEEP. A local machine can still say that its /etc/services, application profile or hand-built configuration associates the two. The first statement controls coordinated assignment. The second describes running or deployable local state. Treating either as a substitute for the other destroys provenance.

RFC 6335 is explicit that all parties to a connection ultimately decide locally which service corresponds to a destination port. IANA's registry supplies a shared default, preventing collisions and reducing configuration. It does not reach into endpoints. A registry mutation has no execution path to rewrite firmware, remove a listener, invalidate a container layer, edit a firewall, close a NAT mapping or update a scanner signature.

The same separation works in the opposite direction. A listener on 831 does not prove NETCONF over BEEP. RFC 7605 warns that assigned port numbers are not guarantees of exclusive use: any service may appear on any number because of misconfiguration or deliberate use. It recommends validating traffic by content. A port scan is evidence of a transport endpoint, not a protocol verdict.

This is where retirement audits often collapse distinct layers. A package database may retain a symbolic name while no service is enabled. A firewall may retain an unused object while no rule references it. A process may listen but reject every association. A client may attempt connections that never complete. A middlebox may label traffic from the number without parsing it. Each record answers a different question.

A defensible local retirement chain begins with scope. Name the device population, software and firmware families, configuration repositories, golden images, orchestration templates, service-name databases, firewall and NAT systems, flow collectors and time window examined. Freeze the query or detection method. Record unreachable assets and retention gaps. “No listener found” without those boundaries is an unreviewable negative claim.

Next, separate configured possibility from observed activity. Search text and structured configuration for the historic names and numbers. Enumerate process and socket state on reachable hosts. Inspect policy-object references rather than merely object existence. Review flow records for attempted associations and packet captures where identification matters. Ask the application or management system whether an authenticated NETCONF exchange completed. Do not let a single dashboard turn these witnesses into one Boolean.

The comparison with surviving NETCONF transports sharpens the boundary. RFC 6242 associates NETCONF over SSH with port 830. RFC 7589 covers NETCONF over TLS and port 6513. RFC 8071 specifies NETCONF and RESTCONF Call Home, including port 4334. RFC 9900 does not release those assignments. A cleanup rule that removes every occurrence of “NETCONF port” would exceed the standard and could damage current management paths.

Future reuse creates another evidence problem. RFC 6335 says a de-assigned number is marked Reserved and should not be reassigned until all unassigned numbers in its range have been allocated. It treats reuse as de-assignment followed by a new assignment and calls for care if broader old use may remain. RFC 7605 goes further: reclamation is practically impossible even when procedures allow it. The danger is not that the registry lacks authority. It is that old packets and configurations do not receive the new meaning atomically.

If one of the numbers is eventually assigned to a different service, the new assignee will hold valid coordination authority. That still will not make every received packet a valid instance of the new protocol. Rollout should begin with a quarantine and observation phase: content-aware canaries, collision telemetry, source population analysis, rate limits and an explicit response to ambiguous traffic. A bare SYN or datagram cannot identify which historical or future meaning the sender intended.

Rollback also has a jurisdiction. An operator can restore a local firewall rule, service-map file or appliance image. It cannot locally reverse the RFC or restore the former global assignment. Once a future reassignment exists, “putting the old name back” may create a collision rather than recover service. The safe rollback unit therefore includes the registry epoch, local configuration version, listener identity, allowed peer set and protocol-content probe.

Heng Lu's Running-Code Primacy supplies the discipline: a standards record coordinates, while operators remain accountable for what their systems actually run. Minimum Initial Specification supports the thin shared registry without pretending it owns every local implementation decision.

Reality Layers explains why a clean registry row can become overpowered evidence. It is precise within its layer, so organizations are tempted to use it as proof about layers it cannot observe. Data Sovereignty makes the complementary point: formal authority over a record and practical control over deployed machinery are related but not identical.

RFC 9900 is good stewardship precisely because it is narrow. It conserves a finite number space, preserves historic names, records the transition and tells operators to reassess residue. Leadership should preserve that precision. The registry can prove that the assignment ended. Only a scoped operational record can show what retired locally—and only packet content and application evidence can show what a live endpoint actually did.

Sources