Zusammenfassung

  • RFC 9900 ist ein IETF Proposed Standard. Er de-assigniert nur die benannten Bindungen: TCP und UDP 831 für NETCONF over BEEP sowie 832 und 833 für NETCONF-over-SOAP-Varianten.
  • Die Dienstnamen netconf-beep, netconfsoaphttp und netconfsoapbeep bleiben erhalten. Die Nummern sind dadurch weder gelöscht noch sofort für beliebige Nutzung frei.
  • RFC 9900 beschreibt Protokolle ohne bekannte Implementierungen oder Produktiveinsätze und hält fest, dass RFC 4743 und RFC 4744 den Status Historic haben. Das ist eine Evidenzgrenze, kein Beweis durch vollständige Suche.

RFC 9900 ist eine Registerpflege und kein neues Protokoll. Die TCP- und UDP-Zeilen für NETCONF über BEEP und die SOAP-Varianten werden aus den Portnummernzuweisungen entfernt. Zugleich bleiben bei 831, 832 und 833 historische Hinweise stehen: Die Nummern waren den genannten NETCONF-Transporten zugeordnet und wurden durch RFC 9900 freigegeben. So wird die Bindung beendet, während die Erklärung ihres früheren Zustands erhalten bleibt.

RFC 6335 behandelt Portnummern als knappe Ressource. Dienstnamen sollen nach einer De-Assignment-Entscheidung bestehen bleiben, weil eine Erschöpfung der Dienstnamen wesentlich weniger gefährlich ist. Eine de-assigned Portnummer wird als Reserved markiert und soll erst dann neu vergeben werden, wenn alle anderen verfügbaren Nummern des einschlägigen Bereichs vergeben sind. Deshalb nennt RFC 9900 keinen Termin für eine neue Zuweisung und erklärt 831–833 nicht zu sofort frei verfügbaren Universalnummern.

Nicht de-assigniert werden NETCONF over SSH auf Port 830, NETCONF Call Home auf 4334 und NETCONF over TLS auf 6513. Der Text erklärt weder NETCONF insgesamt noch alle NETCONF-Transporte für veraltet. Seine begrenzte Betreiberbitte lautet, Konfigurationen neu zu bewerten, die die freigegebenen Nummern weiterhin mit netconf-beep oder netconfsoaphttp verbinden. Weitere neue Betriebs- oder Manageability-Anforderungen führt RFC 9900 nicht ein.

Entscheidungsweg für Betreiber

  1. Prüfen Sie die Registerquelle und die alten sowie neuen IANA-Tabellen; dokumentieren Sie den Reserved-Status statt eine neue Nutzung anzunehmen.
  2. Durchsuchen Sie Service-Dateien, Firewalls, Überwachung, Filter und Diagramme wörtlich nach 831, 832 und 833. Ein Treffer beweist nur eine Referenz, keine Produktivnutzung.
  3. Bewahren Sie die Dienstnamen für beabsichtigte namensbasierte Erkennung, trennen Sie sie aber von einer veralteten Nummernannahme.
  4. Prüfen Sie ausdrücklich, dass 830, 4334 und 6513 nicht in die Änderung einbezogen wurden, und benennen Sie den Lifecycle-Eigentümer jeder Konfiguration.

Konkrete Prüf-Fixtures

  • Registervergleich: Gegenüberstellung der alten und neuen Tabellen aus RFC 9900 für 831–833 einschließlich der historischen Hinweise.
  • Konfigurationssuche: Suche nach 831|832|833|netconf-beep|netconfsoaphttp|netconfsoapbeep; das Ergebnis misst nicht die Zahl realer Installationen.
  • Abgrenzungstest: Separate Prüfung der Einträge für 830, 4334 und 6513, die RFC 9900 nicht de-assigniert.

Quellen