Resumen

  • RFC 9900 desasigna los puertos TCP y UDP 831, 832 y 833, pero conserva los nombres históricos; la nueva fila del registro no reescribe equipos, reglas ni imágenes.
  • Declarar el retiro requiere evidencia negativa acotada y validación del contenido, porque una escucha no identifica por sí sola el protocolo y un registro correcto no demuestra ausencia universal.

El escáner marcó un hallazgo después de la fecha de liberación. Había una escucha en uno de los tres números y una etiqueta automática la llamó NETCONF. El equipo abrió un incidente por “protocolo retirado todavía activo”. Dos horas después descubrió que no había probado el protocolo: solo había unido un número con una antigua tabla de nombres.

Ese error contiene las dos confusiones que RFC 9900 ayuda a separar. El cambio del registro no mata procesos. Y la presencia del número no identifica el servicio.

RFC 9900 desasigna 831 de netconf-beep, 832 de netconfsoaphttp y 833 de netconfsoapbeep en TCP y UDP. RFC 4744 y RFC 4743, que describían BEEP y SOAP como transportes NETCONF, son históricos. IANA mantiene los nombres, elimina su número y registra que aquellos puertos fueron liberados por RFC 9900.

Mantener el nombre es parte del diseño. RFC 6335 trata el nombre de servicio como clave simbólica y el número como recurso compartido escaso. Antes de desasignar, IANA debe establecer razonablemente que el valor ya no se usa. Después conserva una nota histórica y marca el número Reserved. El nombre puede seguir existiendo sin puerto.

Por eso el antes y el después no son “servicio existente” y “servicio borrado”. Son dos relaciones de coordinación. Antes, el registro asociaba nombre, transporte y número. Después, preserva la identidad histórica y deja de coordinar aquel número para el servicio. El cambio protege el espacio común sin fingir que el pasado nunca ocurrió.

En una red privada puede quedar una relación distinta. Una plantilla puede incluir el nombre. Una imagen sin soporte puede conservar la tabla. Un firewall puede permitir el destino. Un cliente antiguo puede intentar conectarse. Esos residuos no derrotan a IANA: son estado local que solo su operador puede medir y corregir.

La frase “no se conocen implementaciones ni despliegues” debe leerse con precisión. Es el estado del conocimiento que respaldó la decisión. RFC 9900 todavía pide revisar cualquier configuración existente que asocie los números liberados con los nombres antiguos. La norma no utiliza su conclusión para borrar la posibilidad de residuo; la convierte en tarea operativa.

Una auditoría debe empezar por el denominador. ¿Se incluyeron dispositivos apagados, laboratorios, copias de seguridad, appliances adquiridos, imágenes doradas, repositorios, archivos /etc/services, objetos de firewall y NAT, firmas de IDS y colectores de flujos? ¿Qué periodo cubren? ¿Qué equipos no respondieron? La ausencia sin población ni ventana no se puede reproducir.

Después hay que distinguir capas. El texto en una plantilla demuestra posibilidad de despliegue, no ejecución. Una socket demuestra escucha, no negociación. Un SYN aceptado demuestra transporte, no NETCONF. Un intercambio que coincide con BEEP o SOAP aporta identidad de protocolo, pero no demuestra que una operación de gestión se autorizó o se aplicó. Cada conclusión necesita su propio testigo.

RFC 7605 advierte que el puerto asignado no garantiza uso exclusivo. Un servicio cualquiera puede aparecer en cualquier número por error o decisión. También señala que la recuperación práctica de números es casi imposible aunque el procedimiento exista. Son dos razones para no automatizar la semántica desde la columna numérica.

El inventario debe preservar la época del registro. Una captura de la tabla actual no explica qué significaba una regla creada diez años antes. La nota histórica de IANA permite reconstruirlo. Para una investigación, conviene guardar el estado del registro observado, la versión de configuración, el propietario del cambio, la escucha, el flujo y el resultado de aplicación con relojes compatibles.

También hay que proteger las rutas NETCONF que siguen vigentes. RFC 6242 mantiene SSH en 830; RFC 7589, TLS en 6513; RFC 8071, Call Home con 4334. RFC 9900 no autoriza una eliminación basada en la palabra NETCONF. Solo trata las asignaciones expresas de 831, 832 y 833.

La futura reutilización no sería simplemente “volver a llenar la celda”. RFC 6335 la modela como desasignación seguida de nueva asignación y exige cautela si el uso antiguo pudo extenderse. El nuevo asignatario tendría autoridad legítima sobre el valor coordinado. No tendría prueba automática de que cada paquete entrante pertenece a su protocolo.

Una puesta en marcha prudente usaría un periodo de cuarentena, canarios que validen contenido, medición de fuentes y tasas, límites para tráfico ambiguo y una decisión explícita sobre colisiones. La semántica nueva comienza en el registro, pero la seguridad comienza cuando el receptor reconoce el protocolo y el contexto correcto.

Tampoco existe un rollback global desde la consola del operador. Puede restaurarse una ACL, una imagen o un archivo de nombres. No puede restaurarse la antigua asignación de IANA. Si el número ya recibiera otro uso válido, volver a la asociación vieja sería una colisión, no una recuperación.

La primacía del código en funcionamiento de Heng Lu obliga a respetar a cada testigo. El registro habla de coordinación. El host habla de procesos. El sensor habla de paquetes. La aplicación habla de operaciones. Minimum Initial Specification sostiene precisamente un núcleo global pequeño y decisiones locales responsables.

Reality Layers explica la tentación de convertir una fila limpia en verdad total. Data Sovereignty separa control formal y capacidad práctica. RFC 9900 hace bien su trabajo: libera la coordinación. La empresa debe hacer el suyo: demostrar qué desapareció de sus sistemas.

Sources